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PREFACE 


BACKGROUND 

The Command and Control Data System (CCDS) Study, in previous 
tasks, analyzed the Space Transportation System (STS) operations 
in order to develop a Department of Defense (DOD) CCDS concept to 
support all STS operations phases. CCDS is a collective term 
since it comprises the ground-based data systems and their inter- 
and intra-system communications required for support of the DOD 
STS. The CCDS concept developed comprised seven functional con¬ 
trol elements: six primarily to support turnaround and launch 
operations and one to exercise overall mission control and to sup¬ 
port operations from liftoff through rollout. These are the Turn¬ 
around Control, Launch Control, Range, Payload Checkout Control, 
Operations Management Control, and Central Data Elements for 
support of turnaround and launch, and for the flight operations 
and mission management, a Mission Control Element. 

The CCDS concept developed is neither a single nor a totally new 
system. Much of the CCDS currently exists in the USAF Satellite 
Control Facility (SCF) and the Vandenberg Air Force Base (VAFB) 
data and communications systems. NASA-operated systems and facil¬ 
ities are to be utilized where possible to avoid expensive duplica¬ 
tions, e.g., mission planning systems or optional use of the 
Tracking and Data Relay Satellite (TDRS) for contingency reaction. 
NASA systems for this study were considered external to the DOD 
CCDS. In applications requiring new equipment, it is expected 
that NASA-developed systems will be installed in DOD facilities to 
the maximum extent possible (e.g.. Launch Processing System). 

The DOD CCDS was considered a functional entity for purposes of 
this study to ensure the compatibility of its several elements by 
developing its functional requirements as an integrated system. 

This will permit subsequent integration of its elements to be ac¬ 
complished efficiently and effectively, and will ensure complete¬ 
ness of the total STS Ground Support System concept. 

Subsequent to the start of this study, a change in the work to be 
done was directed by the Air Force which modified Tasks IV and V. 
Task IV was modified to delete the subtask to define a Shuttle Mis¬ 
sion Control Center (SMCC), which is part of the Mission Control 
Element (MCE). It was replaced with a subtask to define the Air 
Force Satellite Control Facility (AFSCF) and SMCC requirements 




and a subtask to conduct the necessary analysis to define the DOD 
Shu'tie Mission Simulator (SMS) capabilities required. Documenta- 
ti r i resulting from this task is the Orbital Requirements Document 
(ORD) *hich defines the AFSCF/SMCC requirements to support the STS 
operation and volumes IV and V of this report. The ORD is pub¬ 
lished separately and comprises the ORD for support of the Orbiter, 
external tank (ET), and solid rocket boosters (SRB's). A sample 
annex for the ORD defining the requirements levied on the AFSCF 
by the interim upper stage (IUS) is contained in Part 2 of this 
volume. Because of the lack of detail available on the IUS, this 
sample annex is a guide only. It is not a vehicle levying require¬ 
ments on the SCF. Figure 1 illustrates the relationship of this 
task to the other tasks of the DOD STS CCDS Study. 

This volume, in addition to the IUS sample annex to the ORD, pro¬ 
vides backup information, rationale, and/or qualification to mate¬ 
rial contained in the ORD. 


TASK OBJECTIVES 

The task objectives defined in this volume are: 

A. Make a preliminary determination of the operating positions 
required within the SMCC. 

B. Determine the functions to be performed at, and the infor¬ 
mation, control, and communication requirements of, each 
operating position. 

C. . Develop a sample annex to the ORD detailing, to the extent 

possible with current IUS program definition, the support 
requirements levied on the USAF SCF by the IUS. 


ORGANIZATION 

This volume is presented in two parts. Part 1 presents the SMCC/ 
AFSCF requirements analysis results that are not items for the ORD. 
Section 2 includes an estimate of the operating positions required 
within the SMCC to conduct STS operations together with their infor¬ 
mation, control, and communication requirements. Section 3 discusses 
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IV 


Figure 1 Task Interrelationships 






rationale for certain ORD requirements, reasons for some require¬ 
ments being listed as TBD (to be determined), and discussions of 
potential SMCC features considered desirable but not mandatory. 

Part 2 presents the sample annex for the Space Shuttle Vehicle 
ORD containing the IUS requirements for SCF support. This is 
based on the level of detail available at this time. Because of 
the lack of definition of the IUS, the annex is for information 
only. 

Separate tables of contents for Parts 1 and 2 are provided preced 
ing the text in Part 1 and as paragraph 1.5 of Part 2. 
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SECTION 1 


INTRODUCTION 


A major output of Task IV of the CCDS study is the STS Orbital Re 
quiremente Document with Annex l t IUS ORD, which has been pub¬ 
lished separately as PH0-TR584, 14 September 1974. The purpose 
of part 2 of this TOR is to supplement the ORD by: 


• Discussing topics that influence the ORD but are not topics 
within it (e.g., estimate of SMCC operating position require¬ 
ments) 

• Explaining rationale or considerations for certain items 
within the ORD that are TBD. 

• Discussing considerations affecting implementation of Con¬ 
trol, Display, Data Processing, and SMCC interfaces. 





SECTION 2 


SMCC REQUIREMENTS 


STS flight operations were reviewed to determine the ground func¬ 
tions required of the SMCC. Using as a baseline the functional 
organization contained in DOD STS Operations Concept Document 
(Draft), dated 6 August 1974, the SMCC support functions were 
assigned to one or more of the functional groups described in 
that document. If additional functional groups were required, 
such groups were added. Analysis of the functions assigned was 
then accomplished to determine if any functional groups could be 
combined and to recommend the number of operating positions re¬ 
quired within each group. 

This section presents the results of those analyses. 

2.1 OPERATING POSITIONS 

2.1.1 General . This paragraph presents the recommended SMCC op¬ 
erating positions and for each position, it defines the functions 
to be performed and the information, control, and voice communica¬ 
tion requirements. In defining these requirements two functional 
SMCC groups are considered: Orbiter and IUS. 

Figure 2-1 shows the positions and organization of the SMCC in 
support of the Orbiter and IUS. Tables 2-1 and 2-2 list the rec¬ 
ommended positions, define the activity period (nominal and con¬ 
tingency) for each operating position, and identify the type of 
console anticipated for each position (i.e., fixed or general- 
purpose). The fixed console will be used by positions which re¬ 
quire continuous or near-continuous manning. The general-purpose 
console will provide a multifunction operating position. 

2.1.2 SMCC Operating Positions 

2.1.2.1 STS Mission Director (STSMD) . The STSMD will be responsi¬ 
ble for the overall control and direction of all STS flights sup¬ 
ported from the SMCC. He will receive periodic status reports from 
SMCC flight director(s) and make mission management decisions based 
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TABLE 2-1 


SMCC SUPPORT MANNING BY POSITION 


POSITION 

NOMINAL 

CONTINGENCY 

TYPE 

CONSOLE 

STS MISSION DIRECTOR 

X 

X 

FIXED 

FLIGHT DIRECTOR (FD) 

X 

X 

FIXED 

TEST CONTROLLER 

X 

X 

FIXED 

COMMAND CONTROLLER (ORBITER) 


X 

FIXED 

VEHICLE ANALYST (ORBITER) 

X 

X 

FIXED 

ELEC/ENV 


X 

GP 

COMM/INST 


X 

GP 

COMPUTER 


X 

GP 

G&N/CONTROL 


X 

GP 

FLIGHT PLANS/TIMELINE 


X 

GP 

OPERATIONS AND PROCEDURES 


X 

GP 

FLIGHT ANALYST (ORB & IUS) 

X 

X 

FIXED 









TABLE 2-2 

IUS MANNING BY POSITION 


POSITION 

PRE-DEP 

PERIODS 

FREE- 

FLIGHT 

PERIODS 

TYPE 

CONSOLE 

nominal 

CONTINGENCY 

NOMINAL 

CONT OR HIGH 
ACTIVITY 

VEHICLE ANALYST (IUS) 

X 

X 

X 

X 

FIXED 

G&N/CONTROL 




X 

GP 

COMM/INST 




X 

GP 

COMMAND CONTROLLER (IUS) 



X 

X 

FIXED 
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on overall mission and flight crew safety considerations. Primary 
responsibilities of the STSMD are to: 

• Provide overall control and direction of all STS flights 

• Disseminate directives of the STS program office to the 
flight director(s) 

• Initiate mission operational redirection based on mission 
guidelines and objectives 

• Initiate flight termination (if required), lengthen or 
shorten a mission, or redirect Orbiter landing to an alter¬ 
nate landing site 

• Ensure that all support activities are being accomplished in 
a manner that will satisfy flight objectives 

• Approve flight plan changes during inflight operations 

• Approve changes in mission guidelines, mission rules, pro¬ 
cedures, and support requirements 

• Evaluate degree of contingencies based on recommendations 
from supporting positions (flight director) and request ad¬ 
ditional SCF and/or NASA resources. 

Information requirements for the STSMD are: 

• Mission timeline/schedule and present activity point along 
the timeline 

• Groundtrack and present Orbiter location 

• Next station contact (time and ID) 

• Flight plan 

• Status (GO/NO-GO) of flight and ground systems 

• Time, i.e., Greenwich mean time (GMT), ground elapsed time 
(GET), and mission elapsed time (MET) 
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• Next use of Orbiter (time, priority, and location) 

e Alternate landing site status (e.g., weather, landing aids) 

• Ferry aircraft availability 

• New timeline information 
e Payload status (GO/NO-GO) 

e Relative position (Orbiter, satellite, upper stage and de¬ 
ployment/retrieval points) 

• IUS groundtrack/present position 

• Event sequences 

• Contingency alarm (NO-GO status of Orbiter ground systems) 

a Nature of failure, e.g., Guidance and Navigatir (G$N) 

System and trajectory out-of-limits. 

2.1.2.2 Flight Director (FD) . The FD will be responsible to the 
STSMD for mission support of a specific Shuttle flight. During 
nominal mission periods the FD will perform those normal activities 
associated with the overall coordination and supervision of mis¬ 
sion operations. During contingency situations he will be assisted 
by the Flight Plans/Timeline (paragraph 2.1.2.2,A) and Operations 
and Procedures (paragraph 2.1.2.2,B). FD responsibilities are: 

• Manage SCF operational activities in real-time to ensure 
satisfactory accomplishment of mission objectives 

• Direct/redirect STC elements as required to accomplish mis¬ 
sion objectives 

• Determine and direct the accomplishment of alternate command 
plans in real-time 

• Implement alternate procedures to ensure program objectives 
are satisfied 

• Primary voice interface with Orbiter 
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• Provide overall coordination of SCF resources with responsi¬ 
ble agencies when conflicts arise 

• Coordinate with payload Mission Control Center (MCC) user 
and STS disciplines in support of mission mangement decisions 

• Maintain status of landing site 

• Maintain awareness of mission status (GO/NO-GO for mission 
events and activities) 

• Assist STSMD in determination of contingency manning 

• Evaluate degree of contingency and determine need for in¬ 
creased manning when within operational guidelines of the 
STSMD 

• Direct and supervise the implementation of security plans 
and procedures 

• Coordinate the release of all operational communications pe¬ 
culiar to mission support to NASA or other agencies. 

Information requirements for the FD are the same as the STSMD plus 
the following: 

• An additional level of payload status data 

• Flight plan changes and projections of impact to user 

• Flight plan variations 

• Mission activity variations 

• RTS support schedule/capabilities 

• Landing site status* 

A. Flight Plans/Timeline . The Flight Planner (FP) will be 
responsible to the FD for monitoring and updating the mis¬ 
sion flight plan during contingency support periods. Pri¬ 
mary responsibilities of the FP are to: 

• Perform planning, coordination, and implementation of 
all mission activity changes with STS disciplines 


n 


I 
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0 Provide detailed flight plan development and crew pro¬ 
cedures during contingency mission phases to the FD 

• Provide summary planning information for optimization of 
the mission objectives 

• Prepare detailed crew procedures and timeline schedules 
in line with mission objectives and vehicle/crew con¬ 
straints. 

Flight Plans/Timeline information requirements are: 

e Flight plan-baseline/updated 

• Timeline-baseline/updated 

• Crew procedures 

• Crew activities schedule/crew equipment 

• Time 

• Mission rules/objectives 

• Event sequence 

• Mission resources (Orbiter and crew) 

• Groundtrack. 

B. Operations and Procedures (0$P) . The 0§P position will 

provide support to the FD during contingency periods. Re¬ 
sponsibilities of the 0§P position are to: 

• Coordinate implementation of the contingency mission 
control procedures 

• Coordinate data management timelines 

• Coordinate utilization of ground processing and data 
distribution with other team members and remote control 
areas (user MCC) 

• Coordinate recovery of mission data from remote sites 
and data storage. 
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C§P information requirements are: 

• Timeline/schedules 

• Flight plan 

• Next station contact 

• Acquisition of signal/loss of signal times 

• Station configuration and SMCC system status 

• Mission rules/mission objectives 

• Groundtrack 

e Data source/format 
e Time and event sequences. 

2.1.2.3 Test Controller (TC) . The TC will be responsible to the 
FD for the overall command and control coordination between the 
SMCC and the Remote Tracking Station (RTS). Other TC responsi¬ 
bilities are to: 

• Supervise the activities of allocated AFSCF resources 

• Coordinate with network scheduling for normal and contin¬ 
gency scheduling 

• Control voice and data interfaces with RTS's 

• Provide prime SMCC secure voice communications interface 
between the Orbiter and FD 

• Monitor transmission of all program data between the Orbiter 
vehicle and the STC 

• Initiate, control, and conduct all prepass, pass, and post¬ 
pass briefings with support personnel 

• Provide the backup to command and configuration tasks by the 
command controller 

• Coordinate contingency network support with NASA. 
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Information requirements for the TC include: 

• Timeline/schedule 

• National Oceanic and Atmospheric Administration (NOAA) 
weather inputs 

• Flight plan 

• Next station contact 

• Groundtrack 

• SMCC System(s) status - GO/NO-GO 

• Landing site status 

• RTS status/configuration 

• RTS support schedule/capabilities 

• Space Tracking and Data Network (STDN) support status/ 
capabilities 

• Communications plan 

• STS tracking/next station contact 

• Incoming data status, i.e., data sync and data source 
(vehicle) 

• Time 

• Command status/review 

• Command flow 

• Active uplink site/alternate uplink site 

• Command data location 

• Acquisition of signal/loss of signal times 

• Event sequence. 
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2.1.2.4 Command Controller (Orbiter) . The Command Controller (CC) 
will be responsible to the TC for the overall status of the SCF 
command capability tor the Orbiter. This position will be manned 
during contingencies and during periods of activity which require 
increased ground support. Primary responsibilities of the CC in¬ 
clude the following tasks: 

• Monitor and control command generation, review, and transfer 
of real-time commands and command loads 

• Monitor and control SCF network command capability 

• Monitor command flow through SCF network 

• Prepare and recommend changes to the pass plan 

• Complete the command prepass checks 

• Obtain command summaries. 

CC information requirements are: 

• Command status/review 

• Command flow 

• Active uplink site/alternate uplink site 

• Command data location - site loads in core 

• Flight plan 

• Timeline/schedule 

• Time 

• Command verification/reject status 

• Acquisition of signal/loss of signal times 

• Groundtrack 

• Next station contact 

• RTS status/configuration 

• Event sequence. 
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2.1.2.5 Flight Analyst (FA) . The FA position provides support to 
both the IUS and Orbiter during nominal and contingency support 
periods. Functions of the FA in support of IUS operations are 
listed in paragraph 2.1.3.3. 

The FA will be responsible for the trajectory analysis activities 
during all phases of the mission including all ascent trajectory 
monitoring, Terminal Area Energy Management (TAEM), and approach/ 
landing position data. The FA position will monitor and evaluate 
Orbiter and IUS trajectory and provide trajectory status data to 
the FD, other SMCC positions, and user MCC's. This status data will 
permit evaluation of trajectory acceptability and/or permit manage¬ 
ment decisions on maneuvers required to maintain a nominal mission 
or replan for an alternate mission. 

Primary functions of the FA are to: 

• Transmit tracking and commanding prepass tapes and command 
messages (IUS/Tug) 

• Transmit RTS tracking data for Orbiter acquisition and pass 
support 

• Monitor and assist reentry/landing planning operations 

• Monitor and control the offline flight support computer 
scheduling and utilization 

• Maintain mission trajectory profile 

• Provide GO/NO-GO status of Orbiter trajectory to management 

• Analyze trajectory impacts on flight plan 

• Participate in mission design replanning 

• Analyze trajectory impacts on Orbiter systems 

• Update Orbiter ephemeris/state vector (current and desired) 
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• Predict day/night schedules 

• Provide inputs to rendezvous planning 

• Monitor and evaluate Orbiter maneuvers. 

FA information requirements are: 

• NOAA/weather inputs 

• Orbital ephemeris/state vector (current and desired) 

• Flight plan 

• Timeline/schedule 

• Target vehicle state vector 

• Consumables usage tables/Propulsion System's status 

• Station contact schedule 

• STS tracking/next station contact 

• Sun rise/set schedules 

• Acquisition of signal/loss of signal times 

• Command verify/reject 

• Next station contact 

• Time and event sequence 
e Groundtrack 

• Maneuver tables 

• RTS status/configuration. 

2.1.2.6 Vehicle Analyst - Orbiter (VAO) . The VAO will maintain 
top-level status of Orbiter systems status and Orbiter configura¬ 
tion during nominal mission activities. Periodic progress reports 
and mission essential consumables will be maintained by the VAO. 
Significant changes in system status which require real-time ac¬ 
tion will be reported to the FD. The VAO will support prepass ac¬ 
tivities and analyze data resulting from pass or postpass activi¬ 
ties . 
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During contingencies the VAO will be assisted by subsystem per¬ 
sonnel. These positions will be manned as required and will pro¬ 
vide the VAO with periodic mission progress reports and mission- 
essential consumables status reports related to: (1) Electrical/ 
Environmental; (2) Communications/Instrumentation; (3) G§N/Control, 
and (4) Computer Systems. This data will be used to advise the 
FD of mission progress and as tools in replanning if required. 

Primary functions of the VAO are to: 

• Maintain top-level status of Orbiter configuration, i.e., 
vehicle problem analyses and monitor payload/Orbiter inter¬ 
facing subsystem status 

• Analyze flight plan changes impact on Orbiter systems 

• Assist mission management in replanning as required. 

VAO information requirements are: 

• Timeline/schedules 

• Flight plan 

• Orbiter system(s) status - GO/NO-GO and systems data 

• Time and event sequences 

• Consumables tables and maneuver tables 

• Mission rules/mission objectives 

• Command verify/reject 

• Resources (Orbiter, payload, SCF/STDN) 

• Orbiter/target state vector. 

A. Electrical/Environmental . The electrical and environmental 
position is responsible to the VAO, for analysis of the Or¬ 
biter Electrical Power System (EPS) and the Environment Con¬ 
trol System (ECS). The position will report GO/NO-GO status 
based on evaluation of systems performance and trend data. 
Electrical/Environmental information requirements are: 

• Timeline/schedule 
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• Flight plan 

• System telemetry data (batteries, fuel cells, power 
consumption, power distribution and life support 
consumables/systems status) 

• Time and event sequence. 

B. Communications/Instrumentation . The Communications and In¬ 
strumentation position is responsible to the VAO for analy¬ 
sis of the Orbiter communications and instrumentation sys¬ 
tems. This position will report GO/NO-GO status based on 
evaluation of systems performance and trend data. 

Communications/instrumentation information requirements 
are: 

• Timeline/schedule 

• Flight plan 

• System(s) telemetry data (communication: and instrumen¬ 
tation) 

• Time and event sequence. 

C. G5N/Control . The G§N/Control position is responsible to 
the VAO for analysis of the Orbiter G&N and Control Systems. 
This position will report GO/NO-GO status based on evalua¬ 
tion of systems performance and trend data. Functions of 
this position are to: 

• Monitor and evaluate G§N systems performance 

• Evaluate onboard computer information - flight program 

• Monitor and evaluate Orbiter Propulsion System's status 
and trends 

• Monitor and evaluate Attitude Control System's status 
and trends. 
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G§N/Control information requirements are: 

• Timeline/schedule 

• Flight plan 

• Groundtrack/next station contact 

• G§N System telemetry data 

• Maneuver tables 

• STS tracking/next station contact 

• Consumables 

• Time and event sequence 

• Flight program 

• Orbiter state vector 

• Target state vector 

• Landing coordinates. 

D. Computer . The computer position is responsible to the VAO 
for analysis of the Orbiter Onboard Computer System's per¬ 
formance and status. Primary functions of this position 
are to: 

• Monitor and evaluate onboard computer performance, trends, 
and configuration 

• Provide support for onboard software functions. 

Computer position information requirements are: 

• Timeline/schedule 

• Flight plan 
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• Orbiter onboard computer telemetry data such as process 
ing allocation, software monitor, and processor manage¬ 
ment 

• Time and event sequence 

• Flight program. 

2.1.3 Interim Upper Stage (IUS) Operating Positions 

2.1.3.1 Command Controller (IUS/Tug) . The CCIUS will be re¬ 
sponsible to the TC for the SCF command capability for the IUS. 

He will provide the FD with IUS status data and evaluate new mis¬ 
sion requirements impacts. In addition, he will make recommenda¬ 
tions for, and evaluate, flight plan changes. 

Primary functions of the CCIUS are to: 


• Direct command operations at the RTS 

• Generate IUS commands for transmission to RTS and uplink to 
IUS 

• Coordinate IUS/satellite operations for satellite deployment 
and handover involving the IUS 

• Maintain overall status of IUS and flight plan variations 

• Provide assistance to the FD in mission replanning for areas 
pertinent to IUS operation 

• Verify satellite data integrity during IUS/satellite opera- 
ti ons 

• Advise the STSMD and the FD of contingency situation and de¬ 
termine or assist in the determination of corrective action. 

Information requirements for the CCIUS are: 

• Mission timeline and present activity point (Orbiter and 
IUS) 
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• Groundtrack and present location (Orbiter and IUS) 

• Next station contact (IUS) 

• Flight plan 

• Status (GO/NO-GO) of flight and ground systems 

• Time (GMT, GET, MET) 

• New timeline information 

• Payload status (GO/NO-GO) 

• Relative position (Orbiter, satellite, IUS and deployment/ 
retrieval points) 

• Event sequences 

• Mission rules, guidelines, and procedures 

• Satellite/IUS interface status checks 

• Mission planning data (e.g., consumables, consumables trends, 
maneuver tables, and rendezvous tables) 

• System status displays 

• Site acquisition tables 

• Network status 

• Station configuration 

• Command status/review (IUS) 

• Command flow 

• Active uplink site/alternate uplink site. 
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2.1.3.2 Vehicle Analyst - IUS (VAIUS) . The VAIUS position will 
be responsible for maintaining system status of the IUS during 
free-flight or providing assistance in contingency situations when 
the IUS is stowed in the Orbiter payload bay. Some contingency 
situations may require more detailed analysis of IUS subsystems. 
During these periods the VAIUS will be assisted by the IUS G§N/ 
Control and Communications/Instrumentation positions. 

Primary responsibilities of the VAIUS are to: 

• Evaluate proposed flight plan changes for impact to IUS sys¬ 
tems 

• Monitor and maintain status of IUS systems 

• Format and transmit real-time commands and command loads to 
RTS 

• Assist FD in mission planning activities 

• Perform IUS malfunction analysis and recommend corrective 
action. 

Information requirements for the VAIUS are: 

• Mission timeline and present activity point (Orbiter and 
IUS) 

• Groundtrack and present location (Orbiter and IUS) 

• Flight plan 

• IUS systems GO/NO-GO status (e.g., sensor, communications, 
propulsion, instrumentation) 

t Time (GMT, GET, MET) 

0 Additional timeline information and timeline changes 
0 Payload status (GO/NO-GO) 


2-19 


• Event sequences 


• Mission rules, guidelines and procedures as applied to IUS 
systems 

• Satellite/IUS interface status checks 

• System tabs (tabular listing of systems data). 

A. GSN Control . The G5N/Control monitor is responsible to the 
VAIUS for the analysis of IUS G§N, propulsion, attitude 
control, vehicle sequencing and computer. GO/NO-GO status 
will be reported based on evaluation of system status and 
trend data. He will perform malfunction analysis on those 
systems for which he is responsible and will provide assist¬ 
ance to the VAIUS in the determination of contingency sup¬ 
port. The G5N/Control position will be manned during con¬ 
tingency or high activity periods during IUS free-flight. 

Information requirements for the G5N/Control are: 

• Mission timeline and present activity point (Orbiter and 
IUS) 

e Groundtrack and present location (Orbiter and IUS) 

• Flight plan 

• Time (GMT, GET, MET) 

• Additional timeline informatics and timeline changes 

• IUS/satellite interface status 

• Mission rules, guidelines, and procedures 

• 


Event sequences 



• Systems tabs and trends to include inertial measurement 
unit, attitude measuring sensors, attitude control, com¬ 
puter hardware and software, accelerometers, star trackers/ 
horizon sensors, sequential system, main engine, propul¬ 
sion tank management, consumables utilization, mass 
management, and structures and thermal control 

• Maneuver tables 

• Rendezvous tables. 

B. Communications/Instrumentat ion . The Communications/ 

Instrumentation monitor is responsible to the VAIUS for the 
analysis of the IUS communications, instrumentation, and 
EPS. GO/NO-GO status will be reported based on evaluation 
of system status and trend data. He will perform malfunc¬ 
tion analysis on those systems for which he is responsible 
and will provide assistance to the VAIUS in the determina¬ 
tion of contingency support. This position will be manned 
during contingency or high activity periods during IUS free- 
flight. 

Information requirements for the Communications/ 
Instrumentation position are: 

• Mission timeline and present activity point (Orbiter and 
IUS) 

• Groundtrack and present location (Orbiter and IUS) 

• Flight plan 

• Time (GMT, GET, MET) 

• Additional timeline information and timeline changes 

• IUS/satellite interface status 

• Mission rules, guidelines, and procedures 

• Event sequences 
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• System tabs and trends to include power distribution, 
power consumption, batteries, heaters, radiators, com¬ 
munications systems (e.g., S-band, TV), signal condi¬ 
tioners, command receiver, sensors, and multiplexers. 

2.1.3.3 Flight Analyst - IUS (FA1US) . The FAIUS position will be 
combined with the FAO position. For the IUS the FA will provide 
support in orbit determination, ephemeris generation, and maneuver 
planning. In performance of this task he will compare actual tra¬ 
jectory data with desired trajectory and participate in malfunction 
analysis in contingency situations. Primary functions of the FAIUS 
are to: 

• Assist in mission management decision making which requires 
IUS trajectory data 

• Notify satellite user personnel of changes in IUS orbital 
state 

• Perform IUS maneuver and rendezvous planning activities 

• Perform trajectory analysis and make recommendations for 
corrections to non-nominal trajectory profile 

• Prepare and initiate commands and command loads for IUS Or¬ 
bital state corrections. 

Information requirements for the FAIUS are: 

t Mission timeline and present activity point (Orbiter and 
IUS) 

• Groundtrack and present location (Orbiter and IUS) 

• Flight plan 

• IUS systems GO/NO-GO status 

• Time (GMT, GET, MET) 

• Additional timeline information and timeline changes 
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• Payload status (GO/NO-GO) 

• Event sequences 

• Mission rules, guidelines, and procedures 

• Maneuver planning tables 

• Rendezvous tables 

• IUS attitudes 

• IUS mass properties 

• Trajectory profile (Orbiter § IUS) 

• Ephemeris tables (Orbiter § IUS). 

2.1.4 Manning . The SMCC operating positions will provide support 
to both the Orbiter and the IUS. For the Orbiter this support is 
divided into nominal and contingency. For the IUS this support is 
divided into stowed operations and free-flight operations; these 
periods are then further subdivided into nominal and contingency. 

2.1.4.1 Orbiter Manning . During nominal support periods the SMCC 
operating positions to be manned are: STSMD, FD, TC, VAO, and FA- 
Orbiter. It is anticipated that the STSMD will not be on duty at 
all times and in his absence the FD will assume his responsibili¬ 
ties. The other positions would be manned at all times. 

In Task III it was baselined that the amount of contingency support 
will be dependent on the mission situation. In determining the 
manning for contingencies, it is assumed that all contingencies 
will require higher activity in the areas of Flight Plans/Timeline 
and Operations and Procedures. Command and control requirements 
are also anticipated to increase during contingency situations. 
Thus, these positions (Flight Plans/Timeline, Operations and Pro¬ 
cedures, and Command and Control) will be manned for the majority 
of contingency situations. Other positions are for systems support 
and will be manned on an as required basis. These positions are 
Electrical/Environmental, Communications/Instrumentation, G§N/ 
Control and Computer. 
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2.1.4.2 IUS Manning . During nominal support periods when the IUS 
is stowed in the payload bay only the VAIUS position will be manned. 
For nominal periods when the IUS is in free-flight additional sup¬ 
port will be provided by the CCIUS position. 

For contingency support periods when the IUS is stowed in the pay- 
load bay the only IUS support position to be manned is the VAIUS. 
During contingency or high-activity periods (e.g., payload deploy¬ 
ment, midcourse correction planning, and execution) all IUS posi¬ 
tions will be manned to include: VAIUS, G§N/Control, Communications/ 
Instrumentation, CCIUS and FAIUS. 

2.1.5 Console Utilization . Two types of consoles will be used by 
SMCC personnel. These are: fixed and general-purpose. 

Fixed consoles are provided for the STSMD, FD, TC, CC (Orbiter), 

VAO, FA (Orbiter), FAIUS, CCIUS and VAIUS. 

Fixed consoles will be configured as required for these specific 
operating positions. Control modules used for command uplink, 
command enable/disable, and data entry will be provided according 
to individual console requirements. Each console will be provided 
a cathode ray tube (CRT) display, display request module, and 
communications circuits. 

General-purpose consoles will be configured for multifunction usage. 
Generally, these consoles will provide a CRT display device, dis¬ 
play request capability, data entry device and communication cir¬ 
cuits. General-purpose consoles will provide additional support 
capability for contingency situations. Six general-purpose con¬ 
soles will be provided to be used by the Flight Plans/Timeline, 
Operations and Procedures, Electrical/Environmental, Communications/ 
Instrumentation, G5N/Control and Computer operating positions on 
an as-required basis. Two additional general-purpose consoles will 
be provided for contingency support of the IUS. 

2.1.6 Control and Voice Communication Requirements . Table 2-3 
shows the control and voice communication requirements by position. 
Control requirements are divided into display request, command up¬ 
link, command enable/disable and general data entries. Communica¬ 
tion requirements are inter- and intra-center and inter-agency 
voice communication links. 
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2.1.7 Information Requirements . Each of the preceding paragraphs 
describe the information requirements by position in support of 
the Orbiter and IUS. Tables 2-4 and 2-5 present a summary of these 
information requirements by position. 
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TABLE 2-4 

INFORMATION REQUIREMENTS BY POSITION (ORBITER) 


INFORMATION 

MISSION TIMELINE/SCHEDULE 

GROUND TRACK 

NEXT STATION CONTACT 

FLIGHT PLAN 

GO/NO GO SYSTEM STATUS 

TIME 

ORBITER NEXT USE 

ALT LANd SITE STATUS 

FERRY AIRCRAFT AVAILABILITY 

NEW TIMELINE INFO 

00/NO GO PAYLOAD 

RELATIVE POSITION 

IUS GROUND TRACK 

EVENT SEQUENCE 

CONTINGENCY ALARM 

NATURE OF FAILURE 

I'CNE DETAILED PAYLOAD STATUS 

FLIGHT PLAN ChANGES 

MISSION ACTIVITY CHANCES 

ACQUISITION/LOSS OF SIGNAL TIMES 

STATION CONFIGURATION 

MISSION RULES/GUIDELINES/PROCEDURES 

DATA SOURCE/FORMAT 

NOAA/WEF.THER 

GO/NO GO 5MCC SYSTEMS 

GC/NO GO NETWORK STATUS 

LANDING SITE STATUS 

CREW PROCEDURES 

ri: ;sion resources 
CONSUMABLES TABLES 
SYSTEMS DATA (ORBITER) 

COWAND VERIFY/REJECT 

MANEUVER TABLES 

CREW ACTIVITIES 

FLIGHT PROGRAM 

ORBITER STATE VECTOR 

TARGET STATF VECTOR 

SUN RISE/SET SCHEOULE 

RTS STATUS/CONFIGURATION 

RTS SUPPORT SCHEOULE/CAPABILITIES 

STDN SUPPORT STATUS/CAPABILITIES 

COWUN1CATIONS PLAN 

STS TRACKING/NEXT STATION CONTACT 

INCOMING DATA STATUS 

COMMAND STATUS/REVIEW 

COWAND FLOW 

ACTIVE UPLINK SITE/ALTERNATE UPLINK SITE 
COWAND DATA LOCATION 
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FA (ORBITER) 
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TABLE 2-5 

INFORMATION REQUIREMENTS BY POSITION (IUS) 



MISSION TIMELINE/SCHEDULE 
GROUND TRACK 

NEXT STATION CONTACT (IUS) 

FLIGHT PLAN 

GO/NO GO SYSTEM STATUS (IUS) 

TIME 

NEW TIMELINE INFO 
GO/NO GO PAYLOAD STATUS 
RELATIVE POSITION 
EVENT SEQUENCE 

MISSION RULES/GUi DELINES/PROCEDURES 
SAT/IUS I/F STATUS CHECKS 
MISSION PLANNING DATA 
SYSTEM STATUS DISPLAYS 
SITE ACQUISITION TABLES 
NETWORK STATUS 

DETAILED SYSTEMS DATA (STATUS & TRENDS) 

MANEUVER TABLES 

RENDEZVOUS TABLES 

IUS ATTITUDES 

IUS MASS PROPERTIES 

TRAJECTORY PROFILE 

ORBITER STATE VECTOR 

IUS STATE VECTOR 

COMMAND CONFIGURATION 

COMMAND STATUS/REVIEW (IUS) 

COMMAND FLOW 

ACTIVE UPLINK SITE/ALTERNATE UPLINK SITE 
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FLIGHT ANALYST 














2.2 


OPERATIONAL CONCEPT 


The SMCC is that element from which total mission management and 
support of the STS flight elements and operations are conducted. 
During preflight the SMCC will participate in simulations, re¬ 
hearsals, and systems readiness exercises. During flight phases, 
the SMCC maintains sufficient cognizance of Orbiter/IUS trajec¬ 
tories, events, systems status, and crew status to exercise overall 
management of the mission including offline mission replanning. 
Communications are maintained with other CCDS elements as required. 

This paragraph discusses SMCC operations concepts as related to: 

• Command generation and initiation 

• RTS coordination 

• Data entry 

• Display requests. 

2.2.1 Command Generation and Initiation . Commands will be gener¬ 
ated by SMCC software upon request by SMCC operating positions. 
Types of commands to be generated include real-time commands and 
command loads. Real-time commands apply to discrete actions such 
as "recorder dump" or "antenna switching" and would normally be 
stored premission. Command loads apply to onboard system updates 
such as "state vector" update and "time" update and require the 
generation of parameters relative to the type of update. Commands 
will be generated either by specific requests from an operating 
position or by a series of interactive actions between the oper¬ 
ating position and the command generation software. SMCC operating 
positions which will be provided command generation capability will 
be the FA, VAO, VAIUS, CC (Orbiter), CCIUS, and TC. 

Command initiation will provide these same operating positions with 
the capability to initiate a "command uplink" from the SMCC to the 
Orbiter via the RTS. The initiation of a command uplink will occur 
after a command is formatted for output to the Orbiter and will re¬ 
quire the console operator to perform a specific action such as 
pushbutton indicator (PBI) depression. 

Command enable/disable capability is provided to the TC, CC (Orbi¬ 
ter), and CCIUS. Command enable/disable allows a console position 
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to he selected for command initiation. During nominal support 
periods, command enable/disable capability will be performed by 
the TC. During contingency support periods command enable/disable 
will be performed by the CC. For IUS commands during IUS free- 
flight periods command enable/disable capability will be performed 
by the CCIUS. The implementation of the command enable/disable 
capability must also consider requirements by the user to format 
and send commands via the Orbiter when the satellite is under con¬ 
trol of the Orbiter. 

2.2.2 RTS Coordination . Voice contact will be provided between 
the SMCO and the RTS prior to pass support, during the pass, and 
postpass. The FA will perform this function during nominal support 
periods. Contact prior to the pass will be for the transfer of 
acquisition and any changes to the pass support plan, and to verify 
the RTS is configured for Orbiter support. During the pass, coor¬ 
dination will be for the verification of data quality and verifi¬ 
cation that the pass plan is being implemented. Postpass contacts 
will be for problem reporting and to make changes in pass support 
schedules. During contingency situations, the CC position will be 
manned and this position will coordinate RTS support activities. 

2.2.3 Data Entry . Data entry devices will be provided on the 
general-purpose, ~VAO, VAIUS, and FA consoles. Entry devices may 
include alphanumeric keyboards, fixed function keyboards, and pro¬ 
grammable function keyboards. These devices will provide operating 
positions with the capability to request additional information, 
control computer programs, perform interactive data analysis, and 
enter general information. 

2.2.4 Display Requests . Each console will be provided a display 
request capability. TKis capability may be provided through the 
implementation of a display request module, programmable function 
module, or alphanumeric keyboard. The display request module 
would provide only a display request capability. The programmable 
function module would provide for a display request as well as for 
other functions such as program control. The alphanumeric key¬ 
board would provide for data entry as well as display request 
capability. 

Displays will be available to SMCC operating positions dependent 
on mission phase, mission situation (nominal or contingency) and 
predefined mission requirements. Displays will generally be on 
formats specified premission with updates to mission-specific param¬ 
eters according to display requirements. 
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DUAL MISSION SUPPORT 


2. 3 

Dual mission support may be required for two Orbiters or for one 
Orbiter and one Orbiter/IUS/satellite combination requiring simul¬ 
taneous service. In developing a dual mission operations concept 
two functional configurations were assumed as candidates. Config¬ 
uration one (figure 2-2j provides the minimum dual mission support 
capability required by the DOD guidelines listed below. Configur¬ 
ation two (figure 2-3) provides additional capabilities which are 
considered desirable for dual mission support. 

DOD guidelines provided for dual mission support are that: 

• Simultaneous contingency support will not be required 

• Single station RTS's will not be shared 

• SMCC/AFSCF facilities and hardware are "identical" for pur¬ 
poses of mission support, i.e., neither Orbiter has unique 
support requirements 

• It is operationally unacceptable to "time-share" a console/ 
position; this would jeopardize both mission success and 
vehicle safety 

• Payload data may be required from each Orbiter simultaneously; 
payload is used here in the broad concept to include upper 
stages 

• Except for voice, only one data stream would be processed at 
one time 

• Handling of digital voice and recording of data will be pro¬ 
vided for dual missions. 

2.3.1 Configuration 1 for Dual Mission Support . Figure 2-2 pre¬ 
sents an SMCC functional configuration (configuration 1) for sup¬ 
port of DOD dual missions. Foi convenience in defining the SMCC 
support configuration, missions are designated as missions A and B. 
In this configuration, mission A is the primary mission and mission 
B is the secondary mission. As applied to this configuration, 
"primary" refers to the mission for which applications processing 
is provided as a result of high activity, contingency support, or 
nominal processing. "Secondary" pertains to the mission for which 
voice only is being processed and the telemetry data is recorded. 

Inputs to the SMCC consist of Orbiter and payload telemetry and 
voice for both missions. For this configuration the capability 
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Figure 2-2 Dual Mission Support Functional Configurati 








MISSION A OR B VOICE 
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Figure 2-3 Alternate Dual Mission Support Functional Configuration 




is provided for receiving and processing of both downlinks simul¬ 
taneously. Processing consists of receiving A and B mission in¬ 
puts and verifying data quality, communications processing, data 
recording, and stripping out of the digital voice data. Applica¬ 
tions processing is provided for the prime mission. Both a prime 
and backup applications processor are provided for the prime mission. 
Backup applications processing is provided only during contingency 
support periods. In addition, payload data from both the prime and 
secondary mission is routed to the payload data systems for pro¬ 
cessing and distribution to the user MCC's. Digital voice is pro¬ 
cessed and routed to the appropriate mission control areas. The 
capability is provided for voice transmission to/from the separate 
control areas for both missions. Selective voice monitoring capa¬ 
bility of the air-to-ground voice link for either mission from the 
contingency support area is provided. 

Three separate functional areas are provided: mission A control 
area, mission B control area, and a contingency support area capa¬ 
ble of supporting either mission A or B. Coordination voice is 
provided between the control areas and the contingency support 
areas. The control areas discussed in this paragraph are function¬ 
al and need not be implemented as separate facilities or rooms. 

Each primary control area (mission A and mission B) is configured 
with the normal complement of operating positions as defined in 
paragraph 2.1. These include the FD, TC, VAO, and FA (Orbiter), 
the VAIUS, and the CCIUS. The STSMD provides overall direction 
for both missions. 

Two Orbiters may have simultaneous contact with the RTS. During 
these periods, only one mission control area receives real-time 
data, while the other area views recorded data which is processed 
on an as required basis. The determination of which control area 
is to view real-time data is determined by the STSMD based on mis¬ 
sion requirements, mission activity, mission status, and mission 
progress. 

Each control area is provided with the capability for voice com¬ 
munications with the Orbiter assigned to their specific mission. 
Simultaneous processing of Orbiter voice is dependent upon the 
position of the Orbiters and the RTS scheduling constraints. 

In addition, a contingency support area is provided consisting of 
general-purpose operating positions which may be configured to 
support multiple functions. Only one mission will be supported in 
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a contingency mode of operation; the type of contingency will dic¬ 
tate the configuration. Manning of this area is similar to con¬ 
tingency support for a single mission discussed in paragraph 2.2.1. 

A voice monitor capability is provided for the mission requiring 
additional support. 

2.3.2 Configuration 2 for Alternate Configuration for Dual Mission 
Support" An alternate support configuration for dual mission is 
presented in figure 2-3. The addition of a second applications pro¬ 
cessor in this configuration provides the following additional 
capabilities: 

• Simultaneous applications processing provided for mission A 
and mission B telemetry inputs to the SMCC and command out¬ 
puts from the SMCC 

• A backup processor provided for support of either mission A 
or mission B; the backup processor would be online only dur¬ 
ing contingency situations 

• Mission data provided to each mission control area simul¬ 
taneously in support of its respective mission. 
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SECTION 3 


ORD SUPPLEMENT 


3.1 GENERAL 

Based on the program requirement that DOD missions will be con¬ 
trolled from the STC, the ORD was prepared listing the preliminary 
requirements the STS levies on the USAF SCF in support of mission 
control. However, the agency within the USAF responsible for mis¬ 
sion planning and development, flight software development, flight 
crew training, and similar areas has not been specified. Since 
this may not be the SCF, the functions were identified in the ORD, 
but the requirements for them were listed as TBD. As responsibil¬ 
ities for these functions are fixed, analysis to determine the 
total requirements on the SCF (if applicable) can be conducted. 

This section discusses considerations used in determining require¬ 
ments for the implementing of capabilities or rationale concerned 
with "TBD" items in the ORD for the major topics of control and dis¬ 
play, data processing, SMCC communications, the approach and landing 
operations, and the ephemeris requirements. Considerations dis¬ 
cussed are based on previous experience with control systems and 
manned spaceflight support and control. 

3.2 CONTROL AND DISPLAY CONSIDERATIONS 

An SMCC Display/Control System (D/CS) (performing in conjunction 
with SMCC Data Processing, Communications, Command, and Terminal 
Systems) is envisioned for providing mission and support personnel 
the capability of requesting and observing computer-generated data 
displays. (Refer to section 2.) In this capability, the system 
will detect, encode, and transmit console-originated operator re¬ 
quests to the computer systems and generate displays in response 
to these requests, and distribute the display information to the 
desired display equipment. Related requirements will include pro¬ 
vision of a command system permitting user initiation and valida¬ 
tion of SMCC computer-resident or computer-generated commands prior 
to subsequent uplink via RTS. 

Based on previous exposure to similar systems, the nominal D/CS 
will comprise a hardware/software configuration including computer 
input/output equipment, television and digital event generating 
and distributing equipment, and console/group display equipment. 
Primary users of the D/CS will include SMCC operations personnel 
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(comprising flight controllers, network support personnel, in¬ 
flight and postmission analysts, and development/planning groups) 
which will utilize the system for premission software/hardware 
development and equipment scheduling. Summary requirements levied 
on the D/CS by these users (requirements establishing minimum D/CS 
capabilities) will satisfy the following STS program applications. 
(Refer also to tables 2-3, 2-4, 2-5, and 2-6): 

• STS mission operations (online) 

• STS simulations/training 

• Postmission data retrieval and analysis 

• STS activities scheduling and planning 

• STS program development. 

Applications involving the operations and inflight mission evalua¬ 
tion groups will include Orbiter-generated and ground-base-computed 
data, processed and presented in real-time or near-real-time on 
computer driven D/CS display devices throughout prelaunch, ascent, 
on-orbit and reentry phases. In addition, postmission evaluation 
groups will utilize post-operations-processed data displayed in 
the form of computer-generated reports and plots. 

Development/planning group requirements will nominally include dis¬ 
plays generated in nonreal-time from ground-base-generated computer 
inputs, including predefined simulated data and recorded mission 
data. 

3.2.1 Operational STS D/CS Requirements . The interface, distri¬ 
bution, and end device equipment provided by the STS D/CS will 
satisfy two basic user requirements, display and control, which 
are defined as follows. 

A. Display . Presentation of data on wall-type projection dis¬ 
plays, console-mounted digital readout devices, console- 
mounted CRT's, hardcopy printers or recorders, microfilm 
projection equipment, and analog devices. 
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B. Control . Provisions of manually operable keyboards, thumb¬ 
wheels and/or pushbutton switches as required for access to 
computer-resident data, control of hardcopy and microfilm 
facilities, and control of D/CS configurations. 

Major D/CS capabilities required for this support include: 

• Computer input control 

• CRT television generated/distribution 

• Group television 

• Group display (x-y plotters) 

• Digital display (console-mounted event lights) 

• Consoles (multifunction desired) 

• Telemetry display (event light similar to digital dis¬ 
play) 

• Support equipment control/display (configuration 
monitoring/equipment allocation) 

• Analog displays. 

3.2.1.1 Operational Data Categories . Expected data flow to and 
from the SMCC user areas will be one or more of the following 
categories: 

• Television display request, presentation, and updates 

• Group display request, presentation, and updates 

• Program control entry and verification 

• Digital event displays/updates 

• Analog event displays/updates 

• Command entry/verification 

• D/CS configuration management data (resource allocation). 


3-3 


3.2.1.2 Multifunction, Programmable D/CS Considerations . Gener¬ 
ally, assessments of requirements for the operational data flow 
categories listed above were performed in light of a traditional 
central computer-driven display/control environment, wl-rein major 
end devices (consoles in particular) are essentially groupings of 
analog devices and/or transducers directly dependent on the central 
computer for interpretation or origination of their inputs and 
outputs, respectively. 

However, in recognition of more recent trends toward autonomous, 
programmable distribution and end devices, each assessment was 
qualified (where deemed applicable) to note the potential utili¬ 
zation of such techniques. An example would be the assessment 
of general-purpose consoles capable of satisfying the require¬ 
ments of several SMCC control positions (refer to Section 2, 
control positions: Flight Plans/Timeline, Operations and Pro¬ 
cedures, Electrical/Environmental, Communications/Instrumentation, 
G§N/Control). Incorporation of miniprocessing in such consoles 
with the inherent capability to dynamically reconfigure them in 
real-time is a typical "multifunction" consideration which will 
be noted in subsequent paragraphs. 

Similar considerations, relative to D/CS data distributors and 
concentrators, deal with programmable communications controllers; 
for example, configured to a central computer channel but re¬ 
lieving the host computer of numerous I/O overhead tasks. Major 
advantages of such configurations are realized particularly in 
designs where existing processing systems (e.g., existing SCF 
Digital TV processors) are augmented to accommodate expansion with 
minimum impact on the existing processor's operating systems soft¬ 
ware. 


3.2.1.3 TV Displays Utilizing a Centralized Computer System 

3.2.1.3.1 General Data Flow . A TV display request, for either a 
console CRT or a projected group TV screen, will originate as a 
selection at an SMCC user's display request device. The request 
will be received by computer input multiplexing equipment, format¬ 
ted into computer-language words and multiplexed into the SMCC data 
processing equipment. The requested display data is typically 
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output in computer-language format to SMCC TV distribution equip¬ 
ment for display video generation and routing to the requestor's 
designated display device. 

3.2.1.3.2 End Device Requirements and Considerations . Two general 
classes of end devices are identified with TV display requirements: 
display request (input) devices and display presentation (CRT, 
projection screen) devices. 

A. Display Request Devices . Three possible methods to input 
user display requests are envisioned for the SMCC D/CS. 

All are presumed for implementation as console-resident 
devices: 

• Interactive terminal keyboards 

• Fixed function (PBI) panels 

• Programmable (multifunction) panels. 

Detailed requirements for each (quantities, locations, elec¬ 
trical specifications) are TBD as noted in the SMCC/STS ORD 
(paragraph 4.10.6.1.2.1). General considerations necessary 
in determining those requirements, however, should include: 

1. Classes of Data Input . Direct request of preprogrammed 
display for observation only, and callup of display for 
editing/modification (program control entries). 

2. Required Display Usage a nd Response Times . Number of 
frequently used, real-time display requests, compatible 
with fixed (or programmable) function panels requiring 
minimum user-computer interaction for callup, vs number 
of infrequently used, non-real-time display requests 
more compatible with interactive keyboard entry techni¬ 
que. 

3. Flexibility of Display Control Required by Multiple 
Users . Used on general-purpose consoles. Related con¬ 
siderations should deal primarily with programmable 
display request panels which are dynamically reconfig- 
urable either from a central processor or from a console- 
resident miniprocessor (refer to paragraph 3.2.1.3.4). 
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4. Interface Characteristics . Address codes, function 
codes, data formats multiplexing compatibility, and 
physical characteristics (signal leve 1 ^, noise sup- 
presssion techniques, etc.)* 

Display Presentation Devices . Two methods of displaying 
TV data were considered for the SMCC D/CS: console-mounted 
CRT's and group TV (projection TV and/or overhead monitors) 
Detailed specifications for each are TBD as noted in the 
ORD. These specifications will, however, reflect as a min¬ 
imum the following typical considerations: 

1. CRT devices 


• Quantity and location 

• Number of selectable channels 

• Refresh rates 

•> Refresh memory location (computer self-contained 
part of distributors/video switchers) 

• Resolution 

• Scanning parameters 

• Character size 

• Alphanumeric/graphic, capabilities 

• Vector generation capability (if contained within 
CRT unit). 

Projection TV devices 

• Quantity and location of projection screens 

• Image size(s) 

• Type and number of rear projectors 

• Optical throw distances 
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• Projector scanning parameters 

• Resolution 

• Interface characteristics. 

3. Overhead TV Monitors . Considerations will be similar 
to CRT's above, with added consideration for tilt an¬ 
gles, limited display capability (e.g., due to limited 
resolution) ambient lighting levels, etc. 

3.2.1.3.3 TV Data System Distributor/Concentrator Considerations 

A. Display Request Multiplexers/Input Concentrators . In a 

central computer-oriented D/CS, display requests or display 
control entries are traditionally multiplexed from multiple 
console-mounted devices onto the computer I/O channel. It 
uses intermediate equipment to accomplish the multiplexing 
and related format conversion (e.g., keyboard bilevels-to- 
computer language) and signal characteristics conversion 
(levels, rise times, etc.). As noted in the ORD, detailed 
requirements relative to this equipment are TBD. System 
considerations necessary to determine those requirements 
will include the following: 

1. Number of input (display request) devices to be serviced. 

2. Required response time to user-related considerations; 
for example, retired multiplexing speeds, multiplexer 
buffering requirements, priority request requirements, 
and computer channel data rate requirements. 

3. Resource allocation such as priority switching of multi¬ 
plexing capabilities to critical users via program con¬ 
trol or manual control. 

4. Critical path availability, such as redundancy, reli¬ 
ability, automatic failover to backup channels, etc., 
particularly for real-time users. 

5. Interface characteristics, such as computer channel data 
handling conventions and electrical interface specifi¬ 
cations . 
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B. TV Data Distribution . Determination of distribution re¬ 
quirements for TV data will nominally involve the following 
considerations: 

• Computer language-to-video conversion techniques 

• Routing and video switching techniques 

• Quantity and quality of output video channels required 

• Resource allocation control, such as remote manually or 
switchable program-controlled allocation of channels to 
various users 

• General interface characteristics, such as computer chan¬ 
nel data handling conventions, electrical interface char¬ 
acteristics, refresh/update rates, etc. 

3.2.1.3.4 Assessment of Multifunction TV System Capabilities 

A. Miniprocessors in Consoles . Determination of actual user 
end device (CRT, display request input) implementation 
should reflect the assessment of capabilities realized 
.from data processing contained within the user's console, 
(e.g., miniprocessors). Two particular considerations 
should include the following: 

1. Reconfiguration Flexibility . In instances where a 
given general-purpose console may serve multiple users 
(non-simultaneously), rapid reconfiguration of the 
console would be desirable. A nominal method for im¬ 
plementing this capability would be to provide essen¬ 
tially "blank legend" consoles with self-contained 
applications software (selectable by the user via key¬ 
board function code entry) driving the console's legends, 
event lights, etc., in correspondence to the desired 
support function. 

2. Offline Development Compatibility . Residence of display 
applications software within a user's console inherently 
reduces his requirement for online display/request/ 
generation transactions with centralized computer sys¬ 
tems (a feature which not only increases his own response 


3-8 


time but more desirably, reduces time-consuming I/O 
overhead in the central system). For offline program 
development (mission planning, simulations, program 
development) this feature could prove quite feasible. 

A particular advantage can be seen if the SMCC D/CS 
data processing capabilities were implemented as an 
augmentation of the existing STC; i.e., any new unique 
interface handling software, applications handling, 
etc., could possibly be assumed to a large extent by 
the console-resident software. Note: For fixed func¬ 
tion consoles (section 2) programmable console features 
do not appear to have equivalent advantages, but do 
merit similar consideration. 

B. Programmable Data Concentrators/Distributors . A require¬ 
ment of traditional TV distribution systems (distributors/ 
concentrators) is to provide compatibility with computer 
channel data handling conventions (access method functions, 
transmission control functions), in addition to performing 
computer-language-to-video conversion, multiplexing display 
request inputs, etc. A major constraint associated with 
the computer interface is the I/O line handling responsi¬ 
bility assumed by the computer's access method software. 
Programmable I/O controllers (divorced from total dependence 
on the computer's access software, and implemented as part 
of the D/CS distribution) appear to be one method of re¬ 
lieving such constraints, and should be considered in deter¬ 
mining detailed SMCC D/CS requirements. Desirable features 
of these controllers would include the following. 

1. Flexibility . A given controller can be programmed to 
interface distribution systems other than TV (e.g., 
digital event distribution) on a time-shared basis, 
resulting in decreased numbers of dedicated (fixed- 
function by hardware) controllers for each type of data 
distribution. Variable scan rates and formats are re¬ 
lated features. 

2. Reduction o f Central Processing Unit (CPU) I/O Overhead . 
Programmabl I/O controllers nominally assume the line 
handling responsibilities between the computer and the 
display network, relieving the computer of this high 
overhead requirement. 





3. Compatibility with Augmented Systems . In the case 

where an existing system (e.g., SCF) would be augmented 
to incorporate a new system (e.g., SMCC D/CS), the capa¬ 
bility to program the "existing-computer-to-new system" 
interface using standalone programmable controllers 
offers distinct advantages; the major one is reduction 
in modifications to existing I/O software. This advan¬ 
tage should be evaluated in final determination of the 
D/CS requirements. 

3.2.1.3.5 TV Display Hardcopy Considerations . SMCC personnel 
viewing a TV monitor display or projection TV display typically 
desire the capability to hardcopy to given display by initiating 
a hardcopy request from their console. Nominally, the identity 
and location of the requestor will be transmitted with the input 
request to hardcopy control circuits, as switching/routing control 
data. Subsequent switching of the desired video channel to hard¬ 
copy recorder equipment will accomplish the required image con¬ 
version. In addition to the requested display data, the resulting 
hardcopy also includes time-tagging, superimposed on the print. 
Specific hardcopy requirements are TBD as noted in the ORD, (para¬ 
graph 4.10.6.1.2.2). Typical assessments or considerations to be 
made in determining those requirements will include the following. 

• Type of Hardcopy Medium , e.g., thermic or electrolytic photo¬ 
graphic ink jet, direct pen, electrostatic, line printer 

• Resolution 

• Quantity and Access Methods 

• Interfaces , e.g., console, computer channel, video converter, 
video channel switcher, etc. 

• Methods of Output Distribution , e.g., pneumatic tube, hand- 
carry . 

3.2.1 3.6 TV Display Program Development . Refer to paragraph 


3.2.1.4 Group Display Considerations . Large-screen projection 
plotting and X-Y plotters are the two categories of group displays 
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envisioned for the SMCC. Detailed requirements for each are TBD 
as noted in the ORD; general considerations are discussed in the 
following paragraphs. 

3.2.1.4.1 Projection Plots . Large-screen projection plotting dis¬ 
plays nominally originate as selections from operator's consoles. 
The selection data is converted to computer-language format and 
multiplexed into the computing facilities. The computer(s) output 
the associated preprogrammed display data in computer-language 
format to plotting display data distribution equipment. Subsequent 
display/control processing includes conversion of the computer- 
language data to control/distribution data for routing to plotting 
display equipment. Plotting equipment (nominally analog) generates 
the display in a manner suitable for projection onto large display 
screens in the designated area(s). Following initial activation 
of the display, any preprogrammed updates are nominally output from 
the computer to the group display equipment without operator inter¬ 
vention. 

Requirements considerations for this display capability will in¬ 
clude : 

A. Input Request Multiplexing/Data Concentration . Considera¬ 
tions will be similar to those specified for TV display 
requests in paragraph 3.2.1.3.3; i.e., multiplexing, re¬ 
formatting (console input-to-computer language, electrical 
interface compatibility, etc.). 

B. Output Distribution . Output distribution of projection 
plotting data will require assessment computer-language- 
to-analog plotting data conversion, address routing decod¬ 
ing, electrical interface compatibility, and ultimate pres¬ 
entation on plotting screens. 

C. End Devices . Methods for, and consideration of, projection 
plot request devices will be similar or identical to those 
candidates envisioned for TV display requests defined in 
paragraph 3.2.1.3.2 (i.e., interactive terminal, fixed func¬ 
tion keyboard, programmable function panel, etc.). An ex¬ 
ception may be preprogrammed plots which are automatically 
displayed and updated in real-time in certain mission 
phases (e.g., trajectory plots). 
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Requirements for the plotting display presentation will be 
determined from the following (typical) considerations: 

• Screen size(s) and quantities 

• Number and type of scribing projectors required 

• Static background projection requirements 

• Symbol generation requirements 

• Control electronics. 

3.2.1.4.2 X-Y Plotboard Displays . X-Y plotboards in the SMCC are 
envisioned for presenting trajectory plotting data received in 
downlink telemetry data and processed in a preprogrammed sequence 
for presentation. SMCC display/control processing for X-Y plotting 
will include real-time interpretation of the telemetry parameters, 
with subsequent generation and output of the X-Y data in computer- 
language format to required distribution equipment. 

Detailed X-Y plotting requirements will be determined from the fol¬ 
lowing (typical) considerations: 

• Plotboard quantities, types, and locations 

• Amount of downlink telemetry data to be displayed 

• Display formats required 

• Computer language-to-analog plotboard value conversion tech¬ 
niques 

• Manual control (if required; nominally these plots are gen¬ 
erated in a preprogrammed manner with no operator interven¬ 
tion) . 

3.2.1.5 Program Control Entry/Verification . Program control entry 
considerations for the SMCC D/CS encompassed the following user 
entry functions: 

• Display Request . CRT, group display 
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• Command Control . Set up, enable/disable/transmit 

• Program Modification . Display callup for edit/modification, 
program development (nominally offline) 

• Console Reconfiguration . If performed by software, these 
entries could be to either a central processor or a console 
resident miniprocessor. 

Entries will originate at operator's consoles in SMCC user areas. 

The data will nominally be converted to computer language and mul¬ 
tiplexed into the SMCC computers. The computer will verify an 
entry by illuminating an event light(s) at the position from which 
original entry was made. The data flow for this process will require 
the computer to output computer language data to digital display 
distributors for decoding the desired input location and activat¬ 
ing the corresponding digital verification display. 

3.2.1.5.1 Entry Device Considerations . The types of devices con¬ 
sidered for program control entry are those listed previously for 
TV and group display request, including: 

• Interactive terminal keyboard 

• Fixed function PBI panel 

• Programmable function PBI panel. 

A. Interactive Terminal Keyboards . An interactive (with com- 
puter) keyboard is envisioned for many console positions in 
the SMCC. Detailed requirements are TBD as noted in the 
ORD. However, general considerations for determining these 
requirements will include: 

• Cursor controls 

• Alphanumeric entry requirements 

• Graphic control requirements 

• Special function codes 

• Special CRT display editing controls, such as erase line, 
erase page, delete, insert, etc. 

• Light-pen/cursor compatibility 
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• Interfaces such as CRT, central computer, local computer 
(miniprocessor), direct closed-loop to console event 
lights. 

These typical considerations are relative to the keyboard 
device itself. Related major considerations are provision 
of interactive terminal processing software in the central 
computer(s), (refer to paragraph 3.2) and any special ter¬ 
minal communications data concentrators required between 
the central computer and the keyboards. 

For applications involving console-resident software (mini¬ 
processor), considerations must deal primarily with keyboard 
interface software, related console event-light software 
(e.g., keyboard entry verification) and CRT display gener¬ 
ation response to keyboard entries. 

B. Fixed Function Panels . Fixed function panels envisioned 
for the SMCC D/CS will be console-mounted PBI (pushbutton- 
indicators) or event light (illumination only) arrays. The 
fixed function designation refers to the fact that a given 
PBI or event light provides one and only one function (in¬ 
put or event indication) for any user, as opposed to a pro¬ 
grammable panel, whose input or output function may be 
modified dynamically under software control (refer to para¬ 
graph 3.2.1.5.1 ,C). 

General design considerations relative to fixed function 
panels will include (typically): 

• Number of fixed entry parameters required 

• Number of fixed event indications required 

• Interfaces within the console, to external data concen¬ 
trators, or to distributors 

• Program development requirements (refer to paragraph 
3.2). 

C. Programmable Function Panels . While the CRT's/keyboard are 
considered the primary means of display and control at a 
console, and may be all that is required in many fixed con¬ 
sole applications, "programmable function panels" may be a 
desirable supplement to them, particularly in the case of 
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general-purpose consoles. Their use will be determined by 
the operator and controlled by his application programs. 

These panels are normally conceived as "blank legend" event 
light or PBI panels; each panel's function is determined by 
either local (console-resident processor) or remoted central 
processor software. Their utilization requires an operator 
setup entry (e.g., via an associated console keyboard or 
fixed function panel) to select and activate the required 
functional software. 

Considerations which will determine detailed requirements 
for these panels will include utilization of consoles 
(general-purpose in particular). These considerations must 
deal with needs for rapid reconfiguration of and function¬ 
al flexibility of various console panels. If determined 
to be a desirable feature, the following considerations must 
be undertaken. 

• Alphanumeric capabilities 

• Response times 

• Program location and complexity 

• Special effects (blinking, scrolling) 

• Program setup techniques 

• Physical properties such as size, quantities, and loca¬ 
tions . 

3.2.1.6 Digital Event Displays . Digital event display data 
(event lights) activated on occurrence of preprogrammed events 
normally occurs without operator intervention. Detailed require¬ 
ments for generation and routing of those preprogrammed, automat¬ 
ically invoked displays are TBD as noted in the ORD. Determination 
of those requirements will, however, necessitate the following con¬ 
siderations . 


3.2.1.6.1 Distribution Considerations . Digital events may originate 
either in a console-resident or central computer processor. In the 
latter case, distribution requirements will be concerned with 
computer-language-to-analog device activation signals (lamp driver 
voltage conversion, address routing decoding, and distribution of 
event light power to the required end device). Associated design 
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considerations will include redundancy for critical event paths 
and programmable distributor applications (refer to paragraph 
3.2.1.3.3). 

For those digital event indications emanating from console-resident 
miniprocessors (if applicable), distribution requirements would be 
reduced significantly in that they would be limited to "design con¬ 
siderations within-the-console" in most cases, wherein reduced de¬ 
code, conversion, and driver design problems are obvious. 

3.2.1.6.2 Digital Event End Device . Actual digital event indica¬ 
tions nominally occur as illuminations of some end device on a 
console or group display. For console event indications, the fixed 
function or programmable function panels previously mentioned will 
in most liklihood be used. Considerations relative to determining 
their detailed requirements (noted as TBD in ORD) are the same as 
for the panels themselves, i.e., alphanumeric capabilities, rear- 
projection back-1ighting, light emitting diodes (LED's), update 
rates, etc. 

5.2.1.7 Analog Event Display/Control . The D/CS is envisioned 
as requiring analog displays presented on analog stripchart re¬ 
corders and bilevel event recorders. 

5.2.1.7.1 Analcg Stripchart Recorders . Analog stripchart record¬ 
ers arc normally utilised' as a primary means of displaying control 
position and vehicle response data. In addition, the recorders 
may be required for recording selected Orbiter systems data. De¬ 
tailed requirements for the stripchart recorders are TBD as noted 
in the ORD. Those requirements will be established from consider¬ 
ations including: 

• Number of events to be stripped from the downlink telemetry 
streams and the associated processing requirements for con¬ 
version from digital-to-analog 

• Trace amplitudes 

• Number of recorder channels/per unit 

t Quantity/location of recorder. 

3.2.1.7.2 Bilevel Event Recorders . Bilevel event recording 
equipment consists of fixed stili information recording on mov¬ 
ing charts, and are generally used for recording of bilevel 
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engineering events and for biomedical parameters stripped from the 
telemetry downlink. Detailed requirements are TBD as noted in the 
ORD. Considerations relative to determining those requirements 
will include: 

• Signal resolution 

• Chart speeds/regulation 

• Interfaces, [i.e., telemetry ground stations and digital-to- 
analog converters (DAC's)] 

• Locations/quantities. 

3.2.1.8 Command Control Entry/Verification Considerations . Command 
control entries are envisioned for the SMCC D/CS as switch closures 
originating at SMCC user's consoles. The switch closure signals 
will be received by computer input multiplexing equipment, format¬ 
ted into computer language, and multiplexed into the SMCC computers. 
Subsequent action by the computer programs will extract the se¬ 
lected command from predefined storage and output it to a predes¬ 
ignated remote site. 

Verification of command entries will require computer language data 
containing the identity of the originating location to be output by 
the SMCC computer to distribution equipment for decoding and acti¬ 
vation of an appropriate digital display driver, completing the 
entry verification by lamp illumination (event light). 

Requirements for command control systems in the SMCC D/CS will be 
derived from the following considerations. 

3.2.1.8.1 End Devices (Input and Verification) . These consider¬ 
ations are essentially the same as those defined for program con¬ 
trol and event indication devices in paragraphs 3.2.1.5 and 

3.2.1.6. 

3.2.1.8.2 Command Data Processing . Major considerations for 
command control requirements determinations will be the data flow 
processes associated with their generation and execution. These 
considerations, discussed in paragraph 3.5, are summarized here 
to emphasize their implications relative to D/CS. 

A. Command Generation Processing . The command generator should 
be responsive to both manual and automatic requests (where 
indicated). 
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• Generates command data updates for transmission to the 
RTS 

• Formats data into blocks identified by site and trans¬ 
fers data to the prepass data file 

• Recognizes designated levels of constraint violation and 
responds according to mission rules 

• Provides indications, as prescribed, during the command 
generation process 

• Sets the real-time update flag, if there is a need to 
generate commands for a station during vehicle contact. 

B. Command Execute/Modify/Review Processing . Command execute/ 
modify/review programs should provide for the direct up¬ 
link of commands to the Orbiter from the SMCC flight 
and mission controllers. These programs should include 
the following functions: 

• Provide for online inputs from the controllers to allow 
execution and review of the scheduled commands 

• Execute a real-time modified command (modified after the 
prepass command load update) in place of the prepass up¬ 
dated command 

» Recall commands in the currently scheduled RTS command 
load for review, or display a log of the commands trans¬ 
mitted to the RTS 

• Format, by command execute subprograms, the RTS com¬ 
mand index number of the real-time modified command with 
the site ID, and set command message ready flag for the 
communications subprogram. 

• Display the command execute status to the controller who 
executed the current command when the communications sub¬ 
program transmits the command to the site (the command 
capability is distributed to a number of controllers, in 
line with their functional responsibility) 

• Display the Orbiter command action status to the appro¬ 
priate controller upon receipt of a command validate 
message from the RTS, or indication of an excess response 
time interrupt 
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• Record a history of the command and status of the re¬ 
sponse (by the command execute subprogram). 

3.2.1.9 D/CS Configuration Management/Equipment Support Consider¬ 
ations . SMCC D/CS equipment will, based on knowledge of existing 
systems, require configuration control, maintenance and perform¬ 
ance evaluation elements. The support requirements determining 
their scope and complexity will reflect consideration of the 
following support functions: 


• Monitoring computer system selection (online to backup) as 
related to D/CS equipment 

• Performing maintenance functions on D/CS equipment while 
maintaining predefined systems availability 

• Monitoring (within certain critical areas of the D/CS trans¬ 
mission errors, data dropouts, and data loss conditions 

• Manually assigning components and/or selection to redundant 
components, where provided, to enhance system reliability. 


3.3 DATA PROCESSING 


3.3.1 Minimum Requirements . Data processing discussed in this 
paragraph represents a basic core of minimum capabilities required 
by the STC to satisfy STS monitor and support functions. These 
requirements haye been derived from implied or directly stated 
requirements, or are considered logical extensions of those dis¬ 
cussed in current STS requirements documents. 

The detailed requirements of the software capabilities described 
below are defined in the STS ORD, paragraph 4.13. 

A. Front-End Software . Software is required to identify the 
source of data inputs (Orbiter, satellite and/or IUS), and 
the type of data (commands, telemetry) and pass the data to 
appropriate processor modules. This software may also per¬ 
form data conversion/calibration, input message validation, 
and interface message formatting prior to routing inputs to 
other processors. 

B. Data Base Management . Software is required for data base 
definition, security, storage, retrieval, maintenance, and 
interface message processing with data input application 
programs. 

C. Displays . Software is required to provide both requestable 
and forced console CRT displays. Both alphanumeric and 
graphic display capabilities are required to satisfy nominal 
mission status monitoring and contingency support require¬ 
ments. Required capabilities include software for construc¬ 
tion and storage of display skeletons, display request 
recognition/interpretation, display retrieval and console 
routing, dynamic data updating of selected displays, and a 
paging capability for multipage displays. 

D. Limit Sensing/Alarm Generation . Software is required to 
perform limit-sensing of critical vehicle and crew health 
status parameters. Required capabilities shall include 
recognition of candidate parameters upon data receipt, com¬ 
parison of values received with predefined value ranges, 
maintenance of bad value counts to determine an out-of-range 
condition, forced message make-up and appropriate console 
address(es) routing, and interface with display software to 
pass/clear forced alarm messages. 
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E. Keyboard Processor . Software is required to process con¬ 
sole keyboard inputs for display and function execution 
requests. Required capabilities shall include request val¬ 
idation, input error message generation, display retrieval, 
function execution request linkage with appropriate appli¬ 
cation software and display/function output console routing. 
Additional requirements include keyboard capabilities to 
freeze (and release) dynamic data updating of a presented 
display, acknowledge forced caution and warning (C$W) dis¬ 
plays, selectively modify initialized parameter constants 
presented in CRT displays, suppress C$W alarm routing to a 
specified console position, display keyboard inputs in a 
CRT reserved "scratch pad" area, and modify/correct dis¬ 
played keyboard inputs anytime prior to request completion. 

F. Commands Generation . Software s required for command selec¬ 
tion, construction, and transmission through a specified RTS. 
Requirements include capabilities to construct, store, and 
selectively retrieve both "canned" commands and command 
"shells." Keyboard and CRT display interface aids are re¬ 
quired for command selection and to provide a means whereby 
variable parameter data may be input to complete construc¬ 
tion of command shells. 

G. Peripheral Processors . Software is required for access to 
the peripheral devices' I/O services. Device handlers are 
required for input processing from card reader and magnetic 
tape units, and to direct outputs to card punch, line print¬ 
er, and magnetic tape units. 

H. Miscellaneous Functions 

1. Time Display . Software is requiied for dynamic display 
presentation of both GMT and GET. The SMCC time dis¬ 
plays shall be updated once per second to reflect both 
GMT and GET times in hours, minutes, and seconds. 

2. Mission Replanning . This software is required to sup¬ 
port contingency situations which necessitate changes 
to initialized mission planning data. This function 
shall be invoked as a background application upon con¬ 
sole keyboard request and shall include keyboard/display 
software capabilities necessary to selectively modify/ 
recalculate any mission planning parameter(s). 


3. Trend/Analysis . This function provides the capability 
to project/predict specific subsystem parameter values 
based on current or history value inputs and rate of 
consumption/degradation over a specified timeframe. 

This function would be library-resident and invoked for 
background execution upon keyboard request from an 
authorized console position. A series of displays and 
keyboard actions shall provide capabilities to specify/ 
select parameter and time value inputs and present re¬ 
sultant data in CRT displays. (Data results may prove 
useful as inputs to the mission replanning functions.) 


4. Log/Delog . This utility is especially useful as a de¬ 
bug aid during system development and checkout. The 
utility can also be used as a personnel training aid or 
for selective recording and processing of data of pecul¬ 
iar interest during a mission. Selective data/console 
action logging shall be invoked and terminated by a 
computer operator upon direction from authorized mission 
personnel. The delog utility is required for processing 
and line printer output generation of all or a selected 
portion of logged data. Logging shall execute as a back¬ 
ground application in the online computer system. The 
delog utility shall execute as a batch program in either 
an offline computer or the online system, based on avail¬ 
ability of required system resources. 

5. Data Reduction/Statistics . Software is required to pro¬ 
vide (TRD) statistics and summary report outputs on 
specified parameter data. This software shall consist 
of a pool of selectable data reduction routines which 
execute as batch processors. Required mission data base 
dumps shall be loaded into a "history" data base which 
then serves as the data source for processing by selected 
statistics/summary output routines. 

6. Performance Evaluation . Software is required for data 
collection and report generation of system performance 
statistics. Data collection of selected parameters 
(e.g., CPU utilization, idle time, I/O channel utiliza¬ 
tion, etc.) shall be performed in background and output 
to a system log tape. Report generation software shall 
execute as a batch processor and present report outputs 
of logged data on the line printer. 


3-22 


3.3.2 Optional Capabilities . Although not categorized as firm 
requirements, the following capabilities are considered highly de¬ 
sirable to augment those defined in paragraph 3.3.1. 

A. COM . Computer Output to Microfilm (COM) systems are ex¬ 
tremely useful in any system designed to process large 
amounts of data. Today's COM systems typically accept a 
variety of data input rormats with minimal restrictions as 
to data block sizes, special COM control characters, etc. 

A COM system, together with microfilm/microfiche viewers/ 
hardcopiers, provides data output storage condensation and 
a means by which multiple copies of outputs can easily be 
obtained whenever required. 

B. Tape Indexing . A tape indexing system is extremely useful, 
if not a necessity, in any system which requires a sizable 
magnetic tape library for retention of data. A tape index¬ 
ing system provides a means by which the appropriate (set 
of) magnetic tape(s) containing data of interest can quickly 
be retrieved. This capability is basically a software rou¬ 
tine which extracts required descriptive information from 
data tapes and produces a report output correlating data 
descriptions with assigned reel numbers. (A report on data 
base dump tapes, for example, may consist of an ordered 
list with data base number/name, dump date/time, data start/ 
stop frames, and magnetic tape reel number for each tape 
processed.) 

C. Checkpoint . The need for a checkpoint capability is pri¬ 
marily based on recovery requirements in the event that a 
hardware failure results in an unrecoverable loss of mission 
data bases. This capability is probably not required if the 
following statements are valid: 

1. Periodic dumps of critical mission data bases to mag¬ 
netic tape are scheduled throughout a given mission. 

2. In the event of a hardware failure of this type, criti¬ 
cal data bases can be reconstructed from dump tape in a 
reasonably short amount of time (e.g., 30 minutes or 
less). 

3. An unsuccessful recovery (data base reload) attempt will 
not jeopardize the success of a mission. 
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If the above statements are invalid, a checkpoint capability may 
become a firm requirement. The capability primarily consists of 
a disk-to-disk copy utility which permits rapid failure recovery 
through replacement of a "destroyed’' disk with its most recent 
copy. 
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3.4 


APPROACH AND LANDING 


The active role of the mission agent during the landing operations 
and the landing site/MCC interaction are not clearly defined at 
the program level; lienee the reason for the "TBD's" in the STS ORD, 
paragraph 4.5, "Approach and Landing Requirements," concerning 
landing site/SCF coordination and TAF.M assistance. 

The objective of TAEM is to place the Orbiter in a favorable posi¬ 
tion to intercept the final landing approach plane at the correct 
altitude and speed, and the start of TAEM is the final decision 
point for choosing the direction of landing. The Orbiter will have 
the capability to autonomously perform navigation during entry and 
landing, but it is a NASA Level II requirement (Vol. 18, JSC 07700, 
paragraph 3.4.11) that the mission operations computers provide the 
capability to perform backup navigation for the Orbiter during that 
period and the capability to uplink ephemeris data as required to 
assure that safe landing approach conditions are achieved. Only 
when the specific onboard functions for performing TAEM have been 
defined can the SMCC requirements for backup TAEM assistance be 
specified. 

Another area of concern is the mission control -1 anding area opera¬ 
tions and coordination associated with the approach and landing 
operations. Although Level I and II requirements are clear that 
the mission agent, through the MCC or SMCC, retains control of the 
mission until the Orbiter comes to a stop on the runway, the re¬ 
sponsibilities of the personnel at the Landing Operations Area 
(LOA) are not clear. Eor example, the KSC Station Set Requirements 
Document, Vol. 17, "Landing," 19 July 1974 states, "The personnel 
responsible for Orbiter landing operations at KSC will be located 
at consoles in the LOA." One such console is for the KSC Landing 
Operations Director. Since VAFB STS systems and procedures will 
be adapted from the KSC Shuttle ground systems and procedures, it 
is highly likely that there will b a VAFB Landing Operations Di¬ 
rector. His functions must be defined before the SCF requirements 
to support approach and landing can be specified for VAFB landings 
of cither DOD or NASA flights. Similarly, the KSC Landing Opera¬ 
tions Director functions must also be defined before the SCF re¬ 
quirements in support of KSC landings of DOD flights can be speci¬ 
fied. 
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3.5 EPHEMERIS 


Ephemeris requirements contained in paragraph 4.8 of the STS ORD 
do not specify the accuracies required, the time intervals for the 
ephemeris, or the coordinate system to be used. In addition, the 
ephemeris is extended to include the Orbiter's expected position 
vector and velocity during atmospheric flight (until start of 
TAEM). 

The extension of the ephemeris for this program is required to ac¬ 
quire the Orbiter subsequent to blackout in order to provide backup 
navigation and landing assistance and voice communications between 
the SMCC and the Orbiter crew. 

Ephemeris interval and accuracy requirements are expected to evolve 
as the program develops, the test programs are conducted, and the 
results are evaluated. 

A standard set of coordinate systems for the Space Shuttle is to 
be established. This set will comprise the minimal number of coor¬ 
dinate systems required for the practical exchange of data. Cur¬ 
rently, NASA in JSC Internal Note No. 74-FM-15, Candidate Coordinate 
Systems for the Space Shuttle Program, lists a set of 26 candidate 
coordinate systems and states the final set will be developed in 
this calendar year and recommended as the standard set of coordi¬ 
nate systems for the Shuttle program. 
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ACRONYMS AND ABBREVIATIONS 
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A/C 

aircraft 

s. 

AFSCF 

Air Force Satellite Control Facility 


ALT 

Approach Landing Test 

1 ; 

ATP 

Acceptance Test Procedure 


csw 

caution and warning 

1. 

CAPCOM 

spacecraft communicator 


CC 

Command Controller 

i. 

CCATS 

Command, Communications, and Telemetry System 


CCDS 

Command and Control Data System 


CCIUS 

Command Controller-interim upper stage 

7 

CDE 

Central Data Element 

\. 

CDR 

Critical Design Review 


C/O 

checkout 

!. 

COM 

Computer Output to Microfilm 


CPU 

central processing unit 

J. 

CRT 

cathode ray tube 


CY 

calendar year 

L 

DAC 

digital-to-analog converter 


D/CS 

Display/Control System 

1 . 

DOD 

Department of Defense 

. 

ECS 

Environmental Control System 
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EPS 

Electrical Power System 


ET 

external tank 
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EVA 

extravehicular activity 


FA 

Flight Analyst 


I 
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FAIUS 

Flight Analyst-interim upper stage 

FBCS 

fixed base crew station 

FC 

flight controller 

FD 

Flight Director 

FEP 

Front End Processor 

FLT 

flight 

FOD 

Flight Operations Director 

FF 

Flight Planner 

FRR 

Flight Readiness Review 

G5N 

Guidance and Navigation 

GET 

ground elapsed time 

GFE 

government furnished equipment 

GMT 

Greenwich mean time 

GSFC 

Goddard Space Flight Center 

ID 

Identification 

I/O 

input/output 

IUS 

interim upper stage 

IVA 

intravehicular activity 

JSC 

Lyndon B. Johnson Space Center 

KSC 

John F. Kennedy Space Center 

LED 

light emitting diode 

LOA 

Landing Operations Area 

LPS 

Launch Processing System 

MBCS 

Motion base crew station 

MCC 

Mission Control Center 

MCCSS 

Mission Control Center Simulation System 

MCE 

Mission Control Element 

MET 

mission elapsed time 

MOD 

Mission Operations Directorate 
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1 , 

MSC 

Manned Spacecraft Center 


MSFN 

Manned Space Flight Network 

1 . 

NASA 

National Aeronautics and Space Administration 


NOAA 

National Oceanic and Atmospheric Administration 

j 

0§P 

Operations and Procedures 


OAS 

Orbiter Aeroflight Simulator 

S. 

OFT 

Orbital Flight Test 


ORD 

Orbital Requirements Document 

1. 

PBI 

pushbuttom indicator 


PDR 

Preliminary Design Review 

i. 

RF 

radio frequency 


RTS 

Remote Tracking Station 

L 

SAIL 

Shuttle Avionics Integration Laboratory 


SAM SO 

Space and Missile Systems Organization 

i, 

SCF 

Satellite Control Facility 


SDL 

Software Development Laboratory 

i. 

SESL 

Space Environment Simulation Laboratory 


SMCC 

Shuttle Mission Control Center 
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SMS 

Shuttle Mission Simulator 


SOW 

Statement of Work 

i. 

SPS 

Shuttle Procedures Simulator 


SRB 

solid rocket booster 

i' 

ssv 

Space Shuttle Vehicle 


STA 

Shuttle Training Aircraft 

l. 

STC 

Satellite Tesf - Center 


STDN 

Space Tracking and Data Network 

i. 

STS 

Space Transportation System 


STSMD 

STS Mission Director 

' 

TAEM 

Terminal Area Energy Management 
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TBD 

to be determined 

TDRS 

Telemetry Data Relay Satellite 

TOR 

Technical Operating Report 

TV 

television 

VAFB 

Vanderberg Air Force Base 

VAIUS 

Vehicle Analyst-interim upper stage 

VAO 

Vehicle Analyst-Orbiter 

VFT 

Vertical Flight Test 

WIF 

Water Immersion Facility 
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1.2 PREFACE 


This document constitutes an annex to the STS Orbital Requirements 
Document (ORD) and covers those requirements pertaining to the in¬ 
terim upper stage (IUS). The document defines the support required 
of the Satellite Control Facility (SCFJ and furnishes the SCF with 
a basis for planning, implementing and changing hardware and soft¬ 
ware facilities and/or manpower needed to support the STS. 

The format and information content of this ORD Annex are as speci¬ 
fied in SAMSO Exhibit 61-98, Revision B. 


1.3 UPDATING INSTRUCTIONS 


Revisions to this document will be issued by the USAF SAMSO (LV-RO) 
as required to reflect changes in support requirements as they 
occur. It is not intended to revise the document on a scheduled 
basis. 

When revisions are required, each published revision will contain 
the following: 

• Title page with approval signature 

• Updated instructions page 

• Revised summary page 

• Revised table of contents 

• Revised pages 

Page numbers are in consecutive order within each subsection, e.g., 
2.1.1, 2.1.2, 2.1.3. Additional pages required due to a revision 
will be numbered to follow the previous page by the addition of 
consecutive decimal digits, e.g., 2.1.1, 2.1.1.1, 2.1.1.2. Each 
revised page will have the revision number and date of issue. 
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SECTION 2 


GENERAL SYSTEMS INFORMATION 


2.1 PROGRAM 

2.1.1 Program Description . The STS is a new USAF program which 
will employ the Earth Orbiting Space Shuttle, a manned, winged, 
reuseable spacecraft, as well as several configurations of upper 
stage vehicles, for the overall purposes of deploying, servicing, 
retrieving, and returning to earth with DOD satellites. This doc¬ 
ument addresses the on-orbit requirements in support of interim 
upper stage vehicles to be utilized by the DOD during initial 
phase of the STS program; a separate ORD has been prepared for 
the Earth Orbiting Shuttle. 

The upper stage vehicles to be utilized by DOD may be divided into 
two broad categories, as follows: 

A. Early flights of the Shuttle will utilize an interim upper 
stage (IUS) for the sole purpose of transporting and de¬ 
ploying one or more satellites from a low earth orbit (100- 
400 nmi altitude) to a higher altitude not attainable by 

the Shuttle. Many DOD missions are concerned with the place¬ 
ment of satellites in synchronous and/or near-synchronous 
orbits (altitude approximately 19400 nmi). At the release 
date of this ORD the IUS vehicles have not be definitized. 

B. Later flights of the Shuttle will utilize a more sophisti¬ 
cated upper stage, designated as the Tug. The Tug will 
differ from the IUS in two important ways, namely: 

1. The Tug is substantially larger than any IUS vehicle 
mentioned above; consequently, the Tug can transport 
heavier satellites, or it can return with certain DOD 
satellites from synchronous altitude to a low earth 
orbit, such as to permit retrieval of the mated pair by 
the Shuttle. 

2. The Tug will possess the capability to rendezvous with, 
and dock with, satellites in orbits above those achiev¬ 
able by the Shuttle, followed by return to the low 
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Shuttle orbit. By contrast, the IUS vehicles will 
not possess the rendezvous/docking capability. 

DOD flights will originate either at KSC or at Vandenberg Air 
Force Base (VAFB). Only those originating at KSC will utilize 
the IUS; later flights from VAFB may employe the Tug, but retire¬ 
ments for such flights are not yet defined. 

When the vehicle for use as an IUS is determined, it may be pro¬ 
vided systems that would permit its recovery for reuse. For 
purposes of this document, such an IUS is considered to be a 
recoverable IUS. The IUS may not have this capability; even with 
this capability, the IUS may not, on certain missions involving 
heavy satellites and/or a high deployment altitude, possess the 
energy capability to return to the Orbiter following satellite 
deployment. In either of these cases, for the purpose of this 
document, such an IUS is considered to be an expendable IUS. 

in the event of certain anomalous behavior of the IUS and/or its 
mated satellite load, it may be both possible and desirable for 
the IUS to return to a Shuttle-retrieval position rather than de¬ 
ploying the satellite (s) ; in this case an IUS planned to be expend¬ 
able may suddenly become reuseable. Also, in this case ground 
support will become both time and technically critical. However, 
it is emphasized that the IUS cannot rendezvous and dock with a 
satellite; if the IUS is to return a failed satellite to the Shut¬ 
tle rather than executing a deployment, appropriate commands must 
be transmitted from the ground before the deployment is scheduled 
to occur and while the IUS still possesses sufficient propellents. 

During a normal flight an expendable IUS will be preprogrammed to 
perform its intended functions. In these flights support from the 
ground will be limited to tracking and monitoring, and support from 
the Shuttle will be limited to possible final state vector update 
and initiation of the IUS sequences. 

When a reuseable IUS is in flight, most IUS inctions will be pre¬ 
programmed into the vehicle, but additional .pate data may be re¬ 
quired by the IUS, from the ground, for the return to the Shuttle. 


2.1.2 Mission Support . The AFSCF will be required to support IUS 
orbital operations during liftoff, ascent, and all on-orbit phases 
of those DOD-STS flights utilizing an IUS. Details of the AFSCF 
support requirements are provided in Section 4 of this annex. The 
overall control support of each IUS is dictated by the following 
top-level mission requirements: 

A. Obtain tracking data for ephemeris determination. 

B. Provide command generation. 

C. Transmit commands on a secure uplink, as required on an op¬ 
erational basis. 

D. Receive telemetry data on a secure downlink; display and 
distribute data. 

E. Provide for distribution, storage and retrieval of vehicle 
history data, which serves as the basis for remedial action 
in the event of anomalous behavior. 


n 


2.2 ORGANIZATIONAL STRUCTURE 
To be provided by DOD. 
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2.3 LAUNCH SCHEDULES 

IUS launch schedules are contained in Table 2.3-1. 













































2.4 FUNCTIONAL DESCRIPTION 

2.4.1 General. The IUS will be launched while stowed within the 
cargo bay of the Shuttle; DOD program requirements call for launches 
with the IUS only from KSC. Launch windows vary from one mission 

to the next and will be provided as part of the overall mission 
planning for particular missions. During the 1980-1991 period DOD 
is scheduled to fly 76 missions from KSC. Early flights will uti¬ 
lize the IUS, and later flights will utilize the Tug as an optional 
upper stage. 

2.4.2 Launch and Ascent . Following launch the Shuttle, with its 
stowed IUS and attached satellite(s), will be injected into an 
elliptical parking orbit. Perigee and apogee altitudes and the 
orbital inclination are mission-peculiar. As a general rule, the 
Shuttle will orbit at about 100-130 nmi, although certain missions 
call for an apogee up to about 400 nmi. 

2.4.3 Payload Deployment . Following insertion of the Shuttle into 
its parking orbit, the Shuttle cargo bay doors will open and the 
IUS, with its attached satellite(s), will be deployed. Separation 
of this payload combination is designed for a nominal (TBD) fps and 
tipoff angular rate of less than (TBD) deg/sec. The IUS will then 
be reoriented so that its roll axis lies along the velocity vector 
and the IUS altitude control system (ACS) will be activated. 

2.4.4 Payload Postdeployment Events . Following deployment of the 
payload, the Shuttle crew will ensure that the payload orbit is 
stable. The Shuttle will then move to a safe distance (up to 30 
nmi) from the IUS. By radio command from the Shuttle,via a Space 
Ground Link Subsystem (SGLS) RF link, the IUS sequencer will be 
initiated. The IUS propulsion system will then fire in order to 
place the IU3 in a transfer orbit. 

2.4.5 IUS Transfer and Deployment - Expendable IUS . The IUS en¬ 
gine burns following deployment from the Shuttle are intended to 
produce a transfer orbit which will attain the required apogee for 
the satellite(s). The IUS is preprogrammed to perform all guidance 
and navigation functions for this transfer. At near apogee the 
orbit plane will be finalized (plane change) and the orbit circu¬ 
larized. For approximately 75 percent of the DOD flights from KSC, 
the intended satellite orbit is synchronous-equatorial. 

Just prior to satellite deployment the IUS will provide an arm and 
fire signal to separate the satellite. Subsequent to separation 
the IUS will be reoriented, and fired into a non-interfering orbit 
until propellent exhaustion. 
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2.4.6 Post-Satellite Deployment . Full activation procedures for 
DOD satellites are mission-peculiar; typical events may include: 

A. Uncaging of a despin platform 

B. Release of tracking, telemetry and command (TT§C) antennas 

C. Unfurling of solar panels 

D. Satellite spinup (if and as required) 

E. Activation of communications subsystem (this event will occur 
immediately following release from the Shuttle in some mis¬ 
sions) 

F. Drift to final position 

G. Satellite attitude alignment 

Command, checkout, and control of the satellite will be accomplished 
by the AFSCF. 
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2.5 INTERIM UPPER STAGE SYSTEMS 

2.5.1 Functional Relationship Between Subsystems . Subsystems 
include: 

• Controls 

• Propulsion 

• Guidance 

• Communication 

• Navigation 

• Electrical Power 

• Electrical Distribution 

• Structures 

• Thermal Control 

The system mission is primarily accomplished with support from the 
subsystems as follows: 

• Satellite stabilization, station keeping and antenna point¬ 
ing - Controls and Propulsion Subsystems. 

• Ground control for command of functions or adjustments - 
Communications and Controls Subsystems. 

• Primary Electrical Power - Electrical Power Subsystem. 

• Secondary Electrical Power - Electrical Distribution Subsys¬ 
tem. 

• Status and performance monitoring - Communications and Elec¬ 
trical Distribution Subsystem. 

• Spacecraft guidance - Guidance Subsystem. 

• Spacecraft navigation - Navigation Subsystem. 

Spacecraft command and control is implemented primarily through 
onboard stored-program commands of the individual spacecraft 


2.5.1 




functions. Automatic onboard control logic is also incorporated 
into the Electrical Distribution Subsystem for: 

• Spacecraft turn-on and deployment subsequent to separation. 

• Switching of the Communications Subsystem from standby to 
the operational mode during the command process. 

2.5.2 Description of Subsystems . TBD 


2.5.2 



2.6 


MISSION SEQUENCE OF EVENTS 


2.6.1 General . This section outlines the IUS mission events for 
high-altitude deployment missions when the IUS will be recoverable 
by the Shuttle. Mission events for an expendable IUS are suffi¬ 
ciently similar as to not requre elaboration. 

2.6.2 Geosynchronous Deployment Mission 

2.6.2.1 Mission Description . This mission is representative of 
the deployment of a payload into a geosynchronous orbit. The Or¬ 
biter, IUS, and satellite are launched due east from KSC and ascend 
into a 50 x 100 nmi, 28.5 degrees parking orbit. The IUS/satellite 
separates from the Orbiter and performs the necessary phasing, 
transfer and plane change maneuvers to place the satellite at the 
desired longitude location in the synchronous orbit. After satel¬ 
lite deployment, the IUS returns to an orbit 15 nmi above the Or¬ 
biter parking orbit. After IUS retrieval, the Orbiter waits in 
parking orbit (115 nmi) for phasing and return to KSC. 

The IUS/satellite payload will be under Orbiter hardwire monitor 
from liftoff through parking orbit deployment. Predeployment check¬ 
out of the IUS and the satellite will consist of a hardwire, mini¬ 
mal functional check. After deployment, initialization and 
separation, an RF check will be performed by the Orbiter to verify 
the command and control functions. During rendezvous, the Orbiter 
will again perform an RF checkout of the IUS and condition it for 
retrieval. 

2.6.2.2 Orbital Timelines . Two orbital timelines are included in 
this mission description. Figure 2.6-1 is a timeline for the en¬ 
tire flight phase. Figure 2.6-2 shows the IUS timeline for the 
deployment mission. Major events are identified on both timelines. 

2.6.2.3 Mission Sequence . The mission sequence is given in 
table 2.6-1 and is intended for use with figure 2.6-1. Times 
indicated are representative. This mission sequence includes 
representative orbit parameters. 
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Figure 2.6-1 Orbital Activities for Geosynchronous Mission 



Figure 2.6-2 IUS Deployment of Satellite 




2.6.2.4 Flight Operations . Because of its complexity this mission 
has, for presentation purposes, been separated into four on-orbit 
segments. The segments are as follows: 

• IUS outbound transfer orbit phase 

• IUS return transfer orbit phase 

• Orbiter/IUS rendezvous 

• Retrieval by the Shuttle 

Each segment is graphically described in figures 2.6-3 through 
2.6-6. For the most part, the figures are self explanatory. The 
following paragraphs briefly address each segment in more detail. 

2.6.2.5 IUS Outbound Transfer Orbit . As shown in figure 2.6-3, 
checkout of the lUS/satellite combination begins at approximately 
1:36:00 ground elasped time (GET) and is complete by 08:36:15 GET. 
At completion of the deployment, the IUS outbound transfer orbit 
phase begins (figure 2.6-3). 

Depending upon the placement location for the satellite, the IUS 
can begin a direct transfer from the Orbiter parking orbit or can 
execute one or more phasing orbit revolutions to place the IUS in 
a more favorable transfer burn position (the more complex phasing 
orbit maneuver sequence is used to illustrate the transfer burn 
sequence). In the orbit shown (figure 2.6-3) it is essential that 
the IUS place the satellite at a specific location in geosynchro¬ 
nous equatorial orbit, requiring plane changes from the 28.5 degree 
inclination of the parking orbit and two phasing orbit revolutions 
to place the IUS in the required position for the transfer orbit. 

As shown on the mission sequence, table 2.6-1, it is mandatory for 
the IUS to execute the phasing orbit burn at the seventh descending 
node. The burn is executed at 09:18:05 GET and places the IUS in 
a 133 x 3611 nmi/27.9 degrees elliptical orbit. Two revolutions 
in this orbit place the IUS in the proper position for the trans¬ 
fer burn, such that the IUS arrives at synchronous orbit at the 
desired location and inclination. Provision is made for an orbit 
trim during the phasing orbit to adjust the IUS attitude for the 
transfer orbit burn from 76.0 degree inclination. 


TABLE 2.6-1 
MISSION SEQUENCE 


MISSION 

EVENT 

TIME 

(GET) 

1 

LIFTOFF - ORBITER TARGETED FOR 50/100 nml/ 
28.5° 

00:00:00 

2 

SRB STAGING 

00:01:53 

3 

MECO 

00:08:19 

4 

PARK ORBIT INSERT - 50.21/103.5 nmi/28.5 0 

00:08:19 

5 

APOGEE ADJUST - 98/104 nmi/28.49 0 

00:51:01 

6 

CIRCULARIZATION - 134/134 nmi/28.49 0 

01:36:17 

7 

IUS CHECKOUT - (C/0 COMP HALF ORBIT PRIOR 
TO 7TH DESCENDING NODE. TARGETED TO SYNC 
ORBITER POSITION) 

01 :36:1 7 

8 

IUS DEPLOY 

07:36:15 

9 

ORBITER SEPARATE - 131/148 nmi 

08:36:15 

10 

IUS PHASING BURN - 7TH DESCENDING NODE 
133/3611 nmi 

09:18:05 

11 

ORBITER CIRCULARIZE - 138/138 (BEGIN 33 
REVOLUTIONS 

10:50:48 

12 

IUS PHASING REVOLUTIONS (2) 


13 

IUS TRANSFER BURN - 133/19,394 nmi/25.0° 

14:41:57 

14 

IUS ORBIT TRIM 

*17:35:00 

15 

IUS CIRCULARIZATION - 19,300/19,296 nmi 

19:57:26 

16 

IUS ORBIT ADJUST (SYNC ORBIT) 

AS REQ'D 

17 

IUS SATELLITE DEPLOY 

* 31:09:00 

18 

IUS TRANSFER BURN - 164/19,323 (SYNC) 

2 .12° 

43:04:05 

19 

IUS ORBIT TRIM 

» 46:06:00 

20 

IUS PHASING BURN - 164/3439 nmi/27.24 0 

48:21:23 

21 

IUS ORBIT TRIM 

*50:00:00 

22 

IUS CIRCULARIZATION - 165/161 nmi/28.52° 

51 :00:08 

23 

ORBITER RCC BURN - 128/162 nmi/25.51° 

51:55:07 

; 24 

ORBITER EEM BURN - 162/128 nmi/28.50° 

52:43:06 

25 

ORBITER TPI BURN - 145/169 nmi/28.51 0 

53:06:58 

26 

ORBITER TPF - 154/168 nmi/28.49 0 

53:42:58 

27 

IUS RETRIEVAL (START) 

w 53:42:00 
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TABLE 2.6-1 (CONT'D) 


D 

MISSION 

EVENT 

wamm 

0 

28 

EIGHT REVOLUTIONS 


i j 

29 

DEORBIT BURN - 10/161 nmi/28.48 0 

69:25:06 


30 

LANDING 

70:26:01 

i 1 


i 


! 


2 . 6.6 









/ 


2 REVS 


CIRCULARIZATION 



IUS EVENTS PHASING BURN THROUGH OUTBOUND CIRCULARIZATION 


11 

PHASING BURN 

09:18:05 

133/3611 NMI 

27.19 

12 

13 

ORBIT TRIM 
TRANSFER BURN 

14:41:57 

133/19300 

26.0° 

14 

15 

ORBIT TRIM 
CIRCULARIZE 

19:57:26 

19300/19297 

0.0° 


ORBITER NOT SHOWN 

CONTINUES IN PARK ORBIT UNTIL IUS RETURN (33 REVS) 
138/138 NM 28.52° 
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Figure 2.6-3 IUS Outbound Transfer Orbit Phase 
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At 14:41:57 GET the IUS executes the transfer burn at the perigee 
of the phasing orbit (133.0 nmi/26.0°). An orbit trim is executed 
during the transfer orbit ascent to adjust IUS attitude for the 
circularization burn and plane change. Transfer orbit plane and 
circular orbit plane coincide at 19,400 nmi and the IUS executes 
a circularization/plane change burn into a 19,400 * 19,400 nmi/0.0 
degree orbit. Any necessary orbit adjustment is accomplished by the 
IUS and the satellite is deployed. Initiation may be by the IUS 
separation function or by ground command. Complete operational 
checkout of the satellite is the responsibility of the AFSCF ground 
system. Moreover, a predeployment check may be made to determine 
basic command and control capability, such that if the checkout is 
negative, the satellite can be returned by and with the IUS. The 
complete operational check, including sensor stimulus/response, 
can be made only after separation and initialization. 

2.6.2.6 IUS Inbound Transfer Orbit . As stated previously, this 
representative mission has been made complex for illustrative pur¬ 
poses and severe time constraints have been placed on orbit maneu¬ 
vers to indicate requirements; in this case, the IUS phasing orbits 
to adjust to specific deployment requirements. 

If it were not for the time constraint imposed by the IUS de-orbit 
time, a simple direct transfer orbit to the Orbiter parking orbit 
could be made at any time. Assuming, however, that total on-orbit 
time should be minimized, the IUS phasing orbit har been selected 
so that the IUS can be placed within 90 nmi of the Orbiter -- thus 
minimizing rendezvous and retrieval time. The inbound transfer 
orbit is illustrated in figure 2.6-4. 

At 43:04:05 GET, the IUS executes a de-orbit transfer burn into a 
164 x 19,323 nmi/26.12 degree elliptical orbit. The inbound de¬ 
scent requires approximately 5 hours, during which an orbit trim 
maneuver may be required to adjust the IUS attitude for the phasing 
burn. At 48:21:23 GET, the phasing orbit burn is executed at the 
transfer orbit perigee (164 nmi), placing the IUS in a 164 x 3439 
nmi/27.24 degree phasing orbit. After one orbit, the IUS executes 
a circularization burn at the perigee of the phasing orbit, result¬ 
ing in a 165 x 165 nmi/28.52 degree circular orbit, above the Or¬ 
biter parking orbit. 

As shown in the mission sequence, table 2.6-1, the Orbiter is com¬ 
pleting the thirty-third revolution in a 134 x 134 nmi/28.5 degree 
orbit and is within tracking sensor range of the IUS (behind and 
below). 
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IUS EVENTS POST-DEPLOV (RETRIEVAL) 


18 

19 

TRANSFER BURN 
ORBIT TRIM 

43:04:05 

164/19323 

26.12 

20 

21 

PHASING BURN 

ORBIT TRIM 

48:21:23 

164/3439 

27.24 

22 

CIRCULARIZATION 

51:00:08 

161/165 

28.52 
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Figure 2.6-4 IUS Return Transfer Orbit Phase 
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IUS circularization into the rendezvous orbit completes the IUS 
inbound transfer orbit phase. 

2.6.2.7 IUS/Orbiter Rendezvous . The Orbiter is capable of at 
least two types of rendezvous sequences: direct ascent and multi¬ 
revolution, co-elliptic. Direct ascent rendezvous must be 
controlled onboard the Orbiter because network support is not 
available on a continuous basis. Figure 2.6-5 illustrates the 
rendezvous sequence. 

Trajectory calculation for the co-elliptic sequence must be accom¬ 
plished both onboard the Orbiter and by the AFSCF ground system. 

The Orbiter crew must be able to analyze the effect of any correc¬ 
tion burn on the altitude, phasing, and time of rendezvous, while 
the ground system processes the same information to determine 
station contact parameters. The Orbiter assumes prime responsi¬ 
bility as soon as its sensors acquire the target. 

It is illustrated in figure 2.6-5 that the IUS returns to an orbit 
co-elliptical to the Orbiter parking orbit somewhat higher than 
the parking orbit altitude. The specific orbits, shown on the mis¬ 
sion sequence, table 2.6-1, are 134 * 134 nmi for the Orbiter cir¬ 
cular parking orbit and 165 x 161 nmi for the IUS co-elliptic 
orbit. 

Rendezvous between the Orbiter and the returning IUS begins fol¬ 
lowing the IUS circularization burn. As stated, IUS circulariza¬ 
tion is at the perigee of the inbound transfer orbit or (as in this 
case) the phasing orbit. The phasing orbit places the rendezvous 
target within minimum maneuver range of the Orbiter. The Orbiter 
immediately begins rendezvous sensor acquisition. Fifty-four min¬ 
utes later, the Orbiter initiates a sequence of maneuvers resulting 
in rendezvous 2.7 hours after the IUS circularization burn. The 
Orbiter executes a rendezvous corrective combination (RCC) burn and 
a co-elliptic maneuver (CEM) burn to bring it in place for the ter¬ 
minal phase initiation (TPI) and terminal phase final (TPF). Due 
to their small magnitude, the TPI and TPF maneuvers are performed 
using only the reaction control system (RCS). 

The RCC burn is intended to place the IUS orbit 10 nmi above that 
of the Orbiter and to establish a proper phase angle (about -1.1 
degree) at the CEM point. Residual out-of-plane error would be 
corrected by this maneuver. The CEM maneuver circularizes the or¬ 
bit and nulls the residual out-of-plane velocity between the two 
vehicles. Except for attitude control, the IUS becomes passive- 
cooperative for the final phase of the mission; the Orbiter becomes 
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IUS /ORBITER EVENTS - CIRCULARIZATION THROUGH TPF 


22 

IUS CIRCULARIZATION 

51:00:08 

161/165 

28.52 

23 

ORBITER RCC 

51:55:07 

128/162 

28.51' 

24 

ORBITER CEM 

52:43 :06 

149/155 

23.50 1 

25 

ORBITER TPI 

53:06:58 

145/169 

28.51* 

26 

ORBITER TPF 

53:42:58 

154/168 

28.49* 
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Figure 2.6-5 IUS/Orbiter Rendezvous 
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the active vehicle. After the CEM, the phase angle between the 
Orbiter and the IUS is about 1.1 degrees and the Orbiter reduces 
this range from the IUS at a near-constant rate. Approximately 
45 minutes later, the Orbiter reaches the TPI point, and the final 
approach phase of the rendezvous is initiated (53:06:58 GET) on 
the mission sequence. 

2.6.2.8 Retrieval of the IUS . Retrieval operations (illustrated 
in figure 2.6-6) begin at approximately 53:43:00 GET and consist 
of the jettison of any remaining IUS fuel, safing functions, suf¬ 
ficient commands to correct the IUS attitude for retrieval, and 
deactivation of the IUS reaction control system (attitude control). 

Grapple, retract, and securing of the IUS in the payload bay re¬ 
quire no more than 20 minutes and include remating of the IUS 
umbilicals in the payload bay, primarily for safety purposes. The 
spacecraft then prepares for reentry and landing at KSC. 
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IUS /ORBITER EVENTS - RETRIEVAL , DEORBIT, & LANDING 


26 

TPF 

53:42:58 

154/168 

28.49 

27 

RETRIEVAL 

45:02:58 



29 

DEORBIT 

69:25:06 

10/161 

28.48 

30 

LANDING 

70:26:01 
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Figure 2.6-6 Retrieval Phase (Also Illustrates Landing) 
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2.7 GROUND SUPPORT FUNCTIONS 


The AFSCF will conduct the orbital operations required to support 
each IUS deployment mission. The operations support will include: 

• Vehicle tracking of the mated IUS/satellite preceding satel¬ 
lite release. 

• Vehicle tracking of the separated vehicles 

• Telemetry data receiving, recording, processing, and distri¬ 
bution 

• IUS command generation, transmission, and verification 

• Satellite commanding, control, and housekeeping 

This support will be provided by remote tracking stations, as visi¬ 
bility to the vehicles permits, dependent upon mission requirements, 
elapsed time, and station location. Specific support requirements 
are mission peculiar. 

Station scheduling and configuration direction in support of IUS 
flights will be provided by the Satellite Test Center (STC). 

Support requirements include the use of the station SGLS pseudo¬ 
random noise (PRN) signals for range and carrier doppler shift 
(range - rate) , and the optional use of the COMSEC ground equip¬ 
ment for encryption of transmitted commands and decryption of re¬ 
ceived telemetry. The STC will support maneuver command operations 
using ephemeris data supplied by a (TBD) orbit ephemeris system and 
telemetry inputs supplied from the IUS and from the deployed satel¬ 
lite (s). 
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2.8 SCF SUPPORT WORKLOAD 

Tracking support of the mated IUS/satellite(s) will be required 
during the orbital transfer to high altitude to correct possible 
IUS injection errors and to provide the satellite position accuracy 
required to station the satellite(s) at the intended location(s). 
Tracking support is also required for the deployed satellite(s) and 
for the return-to-Shuttle phase for a reuseable IUS. 

Telemetry support will be required during these periods to deter¬ 
mine the status of vehicle subsystems and to determine if attitude 
correction maneuvers, or any other remedial action, are required. 

Tracking and telemetry support requirements will be mission- 
peculiar and will include those tracking stations which have a 
clear line of sight to the IUS and satellite(s) on a scheduled 
basis. It is estimated that minimum support requirements will be 
as follows: 

A. Support for up to (TBD) minutes as soon after deployment 
from the Shuttle as a line-of-sight permits. 

B. Support for at least (TBD) minutes approximately halfway 
through the orbital transfer coast. 

C. Support commencing approximately (TBD) minutes prior to de¬ 
ployment of any satellite from the IUS, and continuing 
through deployment, satellite checkout, commencement of 
satellite operations, and either the initiation of the (re¬ 
useable) IUS return orbital transfer or the depletion burn 
of an expendable IUS. 

D. Support of a reuseable IUS for a minimum of (TBD) minutes 
approximately halfway through the orbital transfer coast of 
a reuseable IUS. 

E. Support contact for up to (TBD) minutes with the Shuttle, 
following retrieval of a recoverable IUS, as line-of-sight 
permits. 
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SECTION 3 


IUS FLIGHT ELEMENT CHARACTERISTICS 

3.1 IUS VEHICLE PARAMETERS 
TBD 


3.1.1 



3.2 IUS TRAJECTORIES 


Each mission utilizing the IUS dictates a unique set of trajectory 
parameters which are defined in the mission annexes. The IUS pro¬ 
gresses through a series of mission dependent flight phases. The 
flight phases include the following: 

• Ascent to satellite ejection orbit 

• Insertion into satellite ejection orbit 

• Satellite ejection orbit 

• Satellite ejection 

• Descent to IUS/Orbiter rendezvous orbit 

• Rendezvous orbit 

Each flight has an attendent set of trajectory parameters. The 
trajectory parameters (depending upon flight phase) include the 
following: 

• Altitude or apogee radius, perigee radius and arguments 
thereto 

• Period 

• Longitude 

• Latitude 

• Ascending node 

• Descending node 

• Inclination angle 

Figures 2.6-3 through 2.6-6 of this annex depict the on-orbit phases 
of a representative recoverable IUS flight profile, beginning with 
deployment from the Orbiter and terminating with insertion into 
rendezvous orbit. 


3.2.1 


3.3 TRACKING 


3.3.1 Tracking Aids 

3.3.1.1 Orbital Transfer Phase . Prior to separation of the satel¬ 
lite^) from the IUS, the satellite systems capable of providing 
tracking assistance are inactive. During this period, angles-only 
tracking information can be obtained by the SCF remote tracking 
stations utilizing the IUS S-band telemetry RF signal. The RF car¬ 
rier frequencies (i.e., SGLS channel selection) for the IUS and its 
mated satellite(s) are mission peculiar and will be selected prior 
to individual missions. Any of the 20 standard SGLS channels may 
be used for the IUS; a separate channel (s) will be used for com¬ 
munications to the satellite(s). During the orbital transfer, 
tracking will occur only between the IUS and one or more SCF ground 
stations. 

3.3.1.2 Orbital Phase . Following separation of the IUS and its 
mated payload from the Orbiter, the SCF remote tracking stations 
will be able to measure the following parameters via the SGLS tele¬ 
metry system: 

• Range through time shift of the PRN range code 

• Range-rate through coherent carrier doppler shift 

• Azimuth ? ->d elevation angle based on the apparent angle of 
arrival or the RF signal transmitted from the IUS. 

3.3.2 Active Tracking System 

3.3.2.1 PRN Ranging . Range is determined by measuring the time 
shift (propagation delay) experienced by a pseudo-random binary 
ranging code which is specifically chosen because of its correla¬ 
tion characteristics. This code, generated in the transmitter 
coder, phase-modulates the ground-to-satellite carrrier, as shown 
in figure 3.3-1. 

3.3.2.2 Doppler Frequency Shift Tracking . Both one-way and two- 
way techniques can be implemented for this range rate tracking 
function. In the two-way technique, a precise determination of 
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range-rate is made possible through the use of the satellite phase- 
locked transponder which generates a coherent carrier at a rational 
fraction (256/205) of the received frequency. The satellite tran¬ 
sponder is interrogated by the ground transmitter operating at a 
frequency of 205/256 times the base frequency (fr x). This results 
in a received signal at the satellite of 205/256 (fr x) plus one¬ 
way doppler shift. This frequency is multiplied by 256/205 in the 
satellite transponder and retransmitted to the ground where it is 
received with additional one-way doppler, as shown in figure 3.3-2. 
Precise range-rate data is extracted through appropriate mixing of 
the filtered received signal from the ground receiver with signals 
from the ground transmitter. Phase-lock techniques are also utilized 
in the ground receiver to provide an efficient tracking filter for 
the received carrier. This technique permits near optimal demodula¬ 
tion of the telemetry and ranging information carried by this signal. 

In the absence of an uplink signal, one-way doppler tracking is pos¬ 
sible by using a stable crystal oscillator in place of the voltage- 
controlled oscillator (VCO) to drive the satellite transponder trans¬ 
mitter. This is termed the "noncoherent" operating mode for the 
transponder. 

The signal is subsequently demodulated in the satellite command re¬ 
ceiver, filtered, and used to remodulate the satellite-to-gromd 
carrier without further processing. This carrier is processed by 
the ground receiving equipment to provide a noise-corrupted, delayed 
replica of the original transmitted signal. A local model of the 
ranging code is generated in the receiver coder and, by a generated 
delay, is made to coincide with the received code through the use 
of cross-correlation techniques. The measured delay with respect 
to the transmitted code is equal to the round trip transit time and 
thus measures satellite range. Once range acquisition has been ac¬ 
complished, the data may be continually updated using internal dop¬ 
pler signals. 

To assure an unambiguous measurement of the satellite range, the 
code period must be greater than the round trip propagation time. 

Two code lengths will be provided for the SGLS; this permits an 
unambiguous range determination to 400,000 nmi for the long code 
and 5000 nmi for the short code. The ranging codes are formed by 
a synchronous combination of four binary code components plus a two- 
bit clock code. To further reduce the time required for acquistion, 
a short code is provided for range uncertainties of less than 5000 
nmi. 
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Figure 3.3-2 Doppler Shift System Block Diagram 





3,3.3 Antenna Gain and Isotropic Antenna Patterns . The IUS will 
employ right-hand circularly polarized antenna subsystem for re¬ 
ception of uplink commands, ranging, and transmission of downlink 
telemetry. It is a DOD requirement that communications to the IUS, 
from a remote tracking station, shall be possible independent of 
the IUS attitude. The onboard antenna subsystem configuration to 
meet this requirement has not yet been defined; correspondingly, 
the antenna subsystem gain and radiation pattern is TBD. Operation 
shall be possible on any of the 20 standard SGLS channels. 




3.4 TELEMETRY DOWNLINKS 


There are two downlinks in the IUS for medium and high-rate tele¬ 
metry. The medium rate telemetry downlink carrier is phase coher¬ 
ent with the uplink carrier and contains a range signal, IUS health 
and status data and command authentication of verification informa¬ 
tion. The high rate telemetry downlink contains satellite data. 

3.4.1 RF Configuration 

Characteristic Requirement 

Frequency range 2200-2300 MHz 

(20 standard SGLC carrier 
frequencies) 

Frequency assignment TBD (mission peculiar) 

Transmitter power output TDB (1.0 watt typical) 

Transmission loss from trans- TBD 

mitter to antenna 


3.4.2 Modulation Technique 

Characteristic Requirement 

Medium rate TLM 


Subcarrier Frequencies 

Subcarrier Modulation 
1.024 MHz 
1.7 MHz 

Subcarrier Frequency 

Tolerance 
1.024 MHz 
1.7 MHz 

Subcarrier Frequency 

Stability 

Telemetry PCM Bit Rate 
1.024 MHz 
1.7 MHz 


1.024 MHz and 1.7 MHz 


PCM/PSK 

PCM/FM/FM 


±60 Hz 
+180K Hz 

TBD 


7.8 b/s to 128 kb/s 
125 b/s to 256 kb/s 


3.4.1 


Characteristic 


Requirement 


Telemetry bit stability 

Telemetry word length 

Telemetry frame length 

PRN modulation technique on 
to carrier 

High rate TLM 

Subcarrier Frequency 

Subcarrier frequency 
stability 

Subcarrier modulation 
technique 

Telemetry data rate 
Telemetry bit stability 
Telemetry word/frame length 


TBD 

TBD 

TBD 

PM 


5 MHz below medium rate TLM 
carrier frequency 

TBD 

PCM/PSK/PM 

128 kb/s to 1024 kb/s 

TBD 

TBD 


3.4.3 Word/Frame Structure . Digital and discrete input signals 
are processed into a PCM time-multiplexed serial bit stream, en¬ 
crypted, and sent to transmitter equipment. 

The mainframe and subframe word structure are TBD. 


3.4.4 Encryption Equipmen t. The IUS may contain GFE TBD telemetry 
encryptors to accept the PCM coded telemetry data and route the 
secured output to the transmitter. 

3.4.5 Antenna Gain Characteristics . The IUS antennas shall have 
TBD gain characteristics. (See paragraph 3.3.3). 

3.4.6 Telemetry Downlink Calculations 

Parameter Nominal Value 


IUS transmitter power 
IUS line losses 


TBD (1-watt typical) 
TBD 




Parameter 


Nominal Value 


IUS diplexer losses 

TBD 

IUS antenna gain 

TBD 

Polarization loss 

TBD 

Space loss at TBD nmi 

TBD 

Atmospheric attenuation 

TBD 

Received power at the ground 
antenna 

TBD 


3.4.3 



3.5 IUS UPLINK 


The uplink carrier is directly phase-modulated by a composite sig 
nal consisting of the PRN ranging signal and the frequency-shift 
keyed command subcarrier frequencies representing the ternary 1. 

0 and S command data. 


3.5.1 RF Configuration 

Characteristic 

Frequency range (assigned 
limits) 

Receiver carrier frequency 
assignment 

Receiver noise threshold 
S/N 

Receiver frequency accuracy 
Command modulation technique 

Command rate 

Command subcarrier frequency 
assignments 

Composite command modulation 
loss (modulation index ■ 0.3 
radian for both commands and 
PRN) 

PRN ranging data 

Composite PRN ranging modula¬ 
tion loss (modulation index 
= 0.3 radian for both com¬ 
mands and PRN) 

Transmission loss from 
diplexer to either receiver 


Requirement 

1750 to 1850 MHz 

(20 standard SGLS carrier 

frequencies) 

TBD (mission peculiar) 

TBD 

±0.002 percent 

Ternary FSK, amplitude modu¬ 
lated with clock waveform 

1 or 2 Kilobaud, ±20 percent 

65 (S), 76 (0) and 95 (1) kHz 
±0.4 kHz 

14.0 dB 


NRZ-L at 500 kb/s 
10.8 dB 


TBD 


3.5.2 Types of Commands . TBD 





3.5.3 


Command Tone Demodulator/Decoder 


3.5.3.1 Signal Reception and Initial Processing . TBD 

3.5.3.2 PRN Ranging . The PRN uplink modulation is detected by the 
phase-locked spacecraft receiver, and the PRN output is supplied to 
the dual baseband assembly for carrier modulation and transmission 
back to the ground station on the telemetry downlink. PRN ranging 
is available in the coherent mode only. The coherent mode exists 
when transmitter No. 1 is operating with receiver No. 1 or trans¬ 
mitter No. 2 is operating with receiver Nj. 2. 

3.5.3.3 Command Modulation . The command carrier modulation con¬ 
sists of three subcarriers turned on one at a time. The subcarrier 
frequencies, listed in paragraph 3.5.1, are assigned to represent 
an S, 0, or a 1. A clock signal is amplitude-modulated on the sub¬ 
carrier signal. The subcarriers are individually keyed at the 
ground station by digital information transmitted from the command 
generator on three digital lines. Condition S, 0, or 1 is trans¬ 
mitted by turning on the corresponding subcarrier fa, fb, or fc, 
one subcarrier at a time, in FSK fashion. The bit-synch informa¬ 
tion (clock) amplitude modulates the keyed subcarrier with a tri¬ 
angular wave at half the bit rate and in suitable phase. 

3.5.3.4 Signal Conditioning . TBD 

3.5.3.5 Command Decoding . TBD 

3.5.3.6 Command Processing . TBD 

3.5.4 Command Word Structure . TBD 

3.5.5 Command Verification . TBD 

3.5.6 Command Uplink Calculation 

Parameter 

Ground station transmitter 
power: 10 kw (dBm) 

Ground station line losses 
transmitter to antenna (dB) 


Nominal Value 
+ 70.0 

- 0.6 
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Parameter 

Nominal Value 

Ground station antenna gain 
(60 ft. dish RHCP) (dB) 

♦ 46.0 

Ground station radome loss (dB) 

-0.6 

Atmospheric attenuation (dB) 

-TBD 

Polarization losses (dB) 

-0.2 

Space loss at TBD nmi (dB) 

TBD 

IUS receiver antenna gain 
±X deg beamwidth (dB) 

♦TBD 

IUS duplexer losses (dB) 

IUS line losses (dB) 

-TBD 

-TBD 

Received power at IUS (dBm) 

-TBD 


3.5.7 Antenna Characteristics. TBD. 
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SECTION 4 


DETAILED SUPPORT REQUIREMENTS 


4.1 PAD CHECK REQUIREMENTS 

SFC support required for the IUS only is as follows: 

• Mission support planning 

• Software coordination 

• IUS/SCF compatibility tests 

• Coordination of data base 

4.1.1 Mission Support Planning . Planning support is required to 
coordinate program requirements with SCF support capability, with 
emphasis on software program interface capability and hardware. 

4.1.2 Software Coordination . Special coordination is required 
between contractors and KSC to ensure compatibility between pre¬ 
launch command and telemetry checkout and KSC support/software 
capability. Normal coordination activities are required in the 
preparation of telemetry modes for data display which are compati¬ 
ble with the IUS telemetry format. 

4.1.3 IUS/SCF Compatibility Tests . Tests will be required at KSC 
to verify the interface compatibility of the IUS Tracking, Tele¬ 
metry, and Command (TTfjC) Subsystem (using engineering model hard¬ 
ware) with the SCF/SGLS hardware. Magnetic tapes of simulated IUS 
telemetry data will be provided by the contractor to verify tele¬ 
metry modes and for use in rehearsals. 

4.1.4 Coordination of Data Base . Data base tables are required for 
the communications ground terminals which will support the Orbiter 
during deployment, mission and recovery of the IUS (when applicable). 
The information required in the tables is TBD. 
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4.2 COUNTDOWN REQUIREMENTS 

There are no IUS-peculiar requirements on the SCF during the count¬ 
down. Upon request from KSC, during the countdown, the SCF will be 
required to report its readiness status via voice link to KSC. 


4.2.1 


4.3 ASCENT REQUIREMENTS 


4.3.1 Definition . The ascent phase for this ORD is from liftoff 
at KSC through separation of boosters and external tasks and in¬ 
jection of the Orbiter into orbit. 

4.3.2 Tracking Requirements . There are no tracking requirements 
peculiar to the IUS during ascent. 

4.3.3 Communications . A voice link is required between the KSC 
and the Orbiter during ascent for backup reporting of IUS status. 


4.3.1 






4.4 ON-ORBIT REQUIREMENTS 

ihc SCF is required to provide prime support to IUS orbital opera¬ 
tions after deployment from the Orbiter. The support required is 
listed in three general categories: maneuvers, communications, 
and IUS operations. 

4.4.1 Maneuvers . During deployment, maneuver, and recovery of the 
IUS, the SCF shall provide backup positional data to the Orbiter or 
guidance update directly to the IUS. These updates, as well as IUS/ 
RTS telemetry, shall be via standard SGLS. 

4.4.2 Communications . SCF communications will be required during 
TBD portions of the IUS flight, as lines of sight permit. Detailed 
utilization of the existing net is TBD, and will be mission-peculiar. 

4.4.3 IUS Operations . Events requiring SCF support include backup 
command transmission, vehicle tracking, data reception, display and 
recording. Specific details are TBD and are mission-peculiar. 



4.5 TRACKING REQUIREMENTS 


4.5.1 SCF Tracking Support . Tracking is required of the SCF to 
meet the specified time and accuracy requirements for updating of 
the IUS ephemeris, to support station handover, command positional 
update, and telemetry reception. Detailed tracking requirements 
are TBD and are mission-peculiar. 

4.5.1.1 Station Acquisition . The activities which will be sup¬ 
ported, and the timelines for groundtracking, are mission-peculiar. 
After IUS deployment, tracking is required for the determination 

of the orbit parameters and the prediction of on-station arrival 
time. During and after deployment, sufficient tracking time per 
day will be allotted to support IUS accuracy requirements. 

4.5.1.2 Repositioning . Ephemeris requirements for IUS update and 
maneuvering are TBD. 

4.5.2 IUS Tracking Planning . The operational planning of IUS 
tracking will be as follows. 

4.5.2.1 Normal Operation . A schedule of normal trajectory and 
maneuvers will be determined in advance and transmitted to the 
field test flight director (F'fFD). The ephemeris will be deter¬ 
mined in accordance with the planned operation and will be provided 
as an input to the station processor for generation of tracking 
slave data and backup commanding. 

4.5.2.2 Contingency Operation . In the event of contingencies in 
IUS operation SCF support is TBD. 


4.5.1 




4.6 EPHEMERIS ACCURACY REQUIREMENTS 

4.6.1 IUS Ephemeris . The accuracy required for the IUS ephemeris 
will vary with the mission phase and is summarized in table 4.6-1. 
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(1) CORRESPOND TO DRIFT RATE ERROR, WHICH IS EQUALLY DIVIDED OVER BOTH ERRORS. ERRORS 
ARE ASSUMED TO BE 100 PERCENT CORRELATED (WORST CONDITION). 

























4.7 TELEMETRY REQUIREMENTS 


4.7.1 Telemetry Support. The requirements for the acquisition of 
telemetry data at the SCF stations are as follows. 

4.7.1.1 Launch Phase . There are no requirements for direct tele¬ 
metry support through deployment of the IUS from the Shuttle. In¬ 
direct support will be achieved via the Shuttle avionics. 

4.7.1.2 Drift Orbit . A TBD-minute sample of telemetry data is to 
be recorded by the SCF in the general telemetry mode (paragraph 
4.7.4) every TBD hours up to initial injection into the final orbit 
or deployment of the payload satellite(s). 

4.7.1.3 Stationing On-Orbit . Continuous telemetry coverage is re¬ 
quired during all commanding in order to arrest and trim drift- 
orbit velocity for station positioning on-orbit. 

4.7.1.4 Attitude/Orbit Maneuvers 

A. Continuous telemetry coverage by the SCF is required during 
all orbit and/or attitude maneuver from TBD minutes prior to 
the first command through TBD minutes after the final com¬ 
mand . 

B. A TBD sample of telemetry data (general mode) is required 
TBD seconds following each attitude/orbit maneuver. 

4.7.1.5 Recording Requirements . All telemetry data received at 
the STC from first acquisition until end of mission will be retained 
for a period of TBD at the STC on magnetic tape. The IUS downlink 
data rate is in accordance with standard SGLS. During this TBD 
period the systems program office (SPO) may request data printed 
out in various modes. 

Recording equipment shall not add errors to the data stream at a 
rate greater than TBD when measured at the recorder output for re¬ 
produced data, referenced to error-free recorder input data. 

The telemetry report format is TBD. 


4.7.1 


1.7.2 Description of the Telemetry List . The description of the 
telemetry list, including explanation of column headings and sort¬ 
ing technique, will be specified for individual missions. 

4.7.3 Telemetry Modes . The number and type of telemetry modes are 
miss ion-peculiar. 

4.7.4 Telemetry Mode Format . All telemetry modes will be designed 
for printing in the same general format. The specifics of this 
format are TBD. 




4.8 CONTROL AND DISPLAY REQUIREMENTS 


4.8.1 SMCC Control and Display (CfiD) . Displays are required at 
the SMCC for Technical Advisor use to display the TLM data as 
specified in paragraph 4.7. These displays will be required 
throughout the entire mission. Other C5D requirements are TBD. 



4.9 COMMANDING REQUIREMENTS 

4.9.1 Command Process Requirement 


4.9.1.1 General Command Operations . Command to the IUS will be 
generated by the SMCC. Command transmission to the IUS is via the 
SGLS which may be secure, if required. The authority to transmit 
types of commands is detailed in paragraph 4.9.1.3. 

Single or block commands will be transmitted. The receipt of com¬ 
mands by the IUS will be verified by telemetry data prior to the 
transmission of subsequent commands. Alarms occurring during com¬ 
mand transmissions must be investigated and analyzed as to possible 
effects on IUS operation prior to transmitting subsequent commands. 
At the end of each command operation, the RTS will forward to the 
Shuttle Mission Control Center (SMCC) a summary of the commands 
transmitted to the IUS. 

4.9.1.2 SCF Support . The IUS will be supported by the SCF in the 
following manner: 

A. Command Sources . Commands which will be sent to the IUS by 
the RTS may emanate from either the command program calcula¬ 
tions under the control of the mission controller or from a 
procedure available to the test controller. 

B. Time-Tagged Commands . Commands sent to the IUS may be time 
tagged. The RTS will comply with the time-tag on the com¬ 
mands within TBD seconds. 

4.9.1.3 Command Authorization . The authorization of commands prior 
to transmission to the IUS will be vested in user agencies, which 
will work through the SMCC. 

4.9.2 Command Description . Detailed requirements imposed upon the 
SCF for IUS commanding clearly must be delayed until the IUS vehicle 
is defined; since the vehicle is still in the conceptual stage as of 
the initial issue date of this document, all such command require¬ 
ments are necessarily TBD. Specifications will eventually evolve 
for commanding IUS subsystems by SCF ground stations, as follows: 

• Communications Subsystems 

• Control Subsystem 
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• Electrical Power Subsystem 

• TT§C Subsystem 

• Electrical Distribution System 

• Structures Subsystem 

• Propulsion Subsystem 

• Thermal Control Subsystem 

• Satellite Separation Subsystem 


4.9.2 


4.10 DATA HANDLING AND DATA DISTRIBUTION REQUIREMENTS 

The data required by the SCF during operational mission consists 
primarily of: 

• Ephemeris 

• Data base 

• IUS status reports 

• IUS telemetry printouts 

• Command program data printouts 

• Command summary 

• KSC reports 

Distribution of each of the above items is listed in tables 4.10-1 
and 4.10-2, 
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DISTRIBUTION OF KSC GENERATED DATA 
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4.11 COMPUTER PROGRAM DEVELOPMENT 


4.11.1 Scope . The IUS contractor will develop a computer program 
to support IUS operation associated with attitude determination 
and correction, station acquisition and maintenance, and the plan¬ 
ning and command generation necessary for accomplishing these opera¬ 
tions. The program will be written in TBD language for use on a TBD 
computer in the standard configuration and software environment and 
shall be compatible with Launch Processing System (LPS) processors 
as well as SCF processing systems. 

4.11.2 Command Program Functions . The program will support and/or 
conduct the following functions and the executive control thereof: 

• Attitude determination 

• Attitude maneuver command data generation 

• Orbital maneuver planning and command data generation 

• Retrieval maneuvers and safing command data generation 

• Telemetry data processing relevant to the above. 

The general performance capabilities applicable tc subprograms of 
the program are: 

A. Present summary data for online decision control, with pro¬ 
vision for outputting detailed data (normally preserved for 
offline listing and analysis), preselectable by user option. 
In general, online output data will include information re¬ 
quired to facilitate validity evaluations and performance 
assessments by user personnel. 

B. Provide the optional capability to override (but not replace) 
control and state parameters in the data base by means of 
function card input. 

C. Format the command sequences both for manual validity, check¬ 
ing at the SMCC and for transmission to the RTS's and Shuttle 
for command backup. These command sequences will include 
commands for preconditioning the vehicle and time tags for 
time-critical commands when applicable. 



D. Interface with STS Orbit Ephemeris System functions, pro¬ 
cedures and/or subroutines for IUS ephemeris data and orbital 
prediction. 

4.11.3 Milestone Schedule . The milestone schedule for the command 
program software is illustrated in table 4.11-1. Also included is 
a milestone schedule for Model TBD software at the SCF which is re¬ 
quired to support the program. 


COMMAND PROGRAM MODELS AND SCHEDULE 
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4.12 TIMING REQUIREMENTS 


The standard SCF timing system which measures time of day in total 
seconds is required on all printouts and command summary printouts 
Time is referenced to GMT. Telemetry printout data lines will be 
time tagged to the nearest whole second at the start of the data 
frame. Command summary printouts will be time-tagged to the near¬ 
est whole second at the initiation of the transmission of the com¬ 
mand word. 

Command Program data printouts require the time of calculated com¬ 
mands measured by year, month, day, hour, minute and seconds (GMT) 
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4.13 COMMUNICATIONS REQUIREMENTS 

The following communications links are required for IUS operations: 

A. Wideband data links between the STC/SMCC and -the RTS's. IUS 
operations require a downlink for a data rate of 16 kb/s and 
uplink data rate (commands) of 1 or 2 kilobauds. 

B. Data links between STC/SMCC and the RTS's for the transmis¬ 
sion of prepass data commands, antenna pointing data and 
ranging data. 

C. Voice an' teletypewriter links between the STC/SMCC and the 
RTS's for control, coordination and administrative functions. 

D. Circuits described in a, b and c between the STC and KSC 
for launch coordination. 
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4.14 FACILITIES REQUIREMENTS 

The following additional facilities will be required for IUS opera¬ 
tions : 

TRD 
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4.15 OTHER REQUIREMENTS 

4.15.1 STC/SMCC Reports . TBD 

4.15.2 Data Base . The STC/SMCC shall provide a data base in sup¬ 
port of IUS scheduling and acquisition times. The information in 
the data base will be supplied for each mission via magnetic tape. 

The required data to be provided for each mission data base includes: 

• Ground trace table 

• RTS acquisition table 

• Events tables 

Rise and fade times (5° elevation points) for each RTS 
Shuttle, IUS and payload conjunctions 

• Orbital elements (ADBARV format may be specified) 

The following descriptions provide specific definition of require¬ 
ments for data derived from IUS ephemerides: 

TBD 
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